Date: Mon, 5 May 2014 13:23:50 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-standards@freebsd.org Subject: Re: standards/189353: POSIX sem_unlink does not actually unlink the semaphore in the process context Message-ID: <20140505125518.N1229@besplex.bde.org> In-Reply-To: <20140504221736.GA65318@stack.nl> References: <201405041830.s44IU1cI097827@freefall.freebsd.org> <20140504221736.GA65318@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140505125518.N1229>