standards/189353: POSIX sem_unlink does not actually unlink the semaphore in the process context

[Bruce Evans]

On Mon, 5 May 2014, Jilles Tjoelker wrote:

> On Sun, May 04, 2014 at 06:30:01PM +0000, Konstantin Belousov wrote:
> ...
>> > It looks like glibc is using inodes numbers and dev number for that,
>> > which, while not being strictly correct (inodes can be reused), seems
>> > to work fine on linux.
>>  Inode number + generation provides the same practical guarantee as the
>>  file descriptor.  You cannot have two inodes with the same (inum, gen)
>>  simultaneously, generation would need some years to wrap.
>
> Unfortunately, st_gen is zeroed for users without PRIV_VFS_GENERATION
> (this is to make it harder to forge NFS file handles). As a result, it
> works less well for non-root users and may incorrectly not reuse a
> nameinfo if the process dropped root privileges between opens.
>
> Instead, you could use st_birthtim; since there is no specified API to
> set timestamps on semaphores, it should never change.

To hijack this thread...

setutimes() has support for setting btimes^Wbirthtimes if the caller
passes a btime, but no callers pass a btime.  It sets the btime to the
mtime if the current btime is after the new mtime.  Thus userland callers
can intentionally change (or unintentionally corrupt) the btime by
frobbing with the mtime.  The MAC check in setutimes() doesn't support
btimes even when they are passed.

I recently used my hack for frobbing ctimes so as to store or restore
them to consistent values in backups.  It is not such a good hack as
the btime one.  I probably want backup backup programs to preserve
btimes too, but currently don't notice their inconsistencies since
my attribute checking program doesn't support them.  It also doesn't
support ACLs...

futimes() works on file descriptors.  Does it work on semaphores?

All time-setting APIs still seem to be broken as designed, since they
only support setting timevals but file times are timespecs.  Thus it
is impossible to back up, restore, or otherwise preserve file times
in the general case.  I mostly avoid this problem by not using high
vfs.timestamp_precision values.  If btimes are uses as identifiers,
then they should use full timespec precision and not honor
vfs.timestamp_precision, but then accidental corruption of them using
standard APIs to "preserve" them is even easoer.

Bruce