> > >Actually, as I look around more, I see that some > other systems > >(*BSD, Linux, QNX) have one or both of lchmod(), > flink(). One > >argument used for both even if they otherwise seem > silly is avoidance > >of race conditions, although I've seen > counter-arguments for flink(), > >but I didn't quite understand them - maybe they're > Linux-specific. > > > lchmod() is something we really ought to have; not > because the permissions > of symbolic links matter but because you don't want > to follow links when > you do a chmod. > > E.g., with both chown -R and chmod -R you don't want > to change what is at > the end of symlinks.
Right - and there's also compatibility, since some other OSs have lchmod() and something like chown's -h option for their chmod command. In which case, maybe behavior of lchmod() should change: you want it to function without following symlinks, and fail (with what errno?) if its target turns out to be a symlink, rather than setting the (irrelevant) permissions on the symlink. > flink() is problematic because it requires you to > find the appropriate > device to create the link in AND it may allow you to > upgrade the access > to the file. (>E.g., you get a read-only > filedescriptor which is hidden > somplace and which has mode 666; flink would allow > you to upgrade to > write access. Yeah, I finally understood that to be the argument opposing it, from the discussion about adding flink() to Linux. So I agree we'd be better off without it, notwithstanding that other OSs (QNX is the one I know of) have it. [...] And indeed some of the Linux folks were pointing out that link()ing to /proc/*/fd/N should also _never_ be allowed, for the same reason (the opportunity to escalate access to a file whose name was only in a locked-down directory, but whose fd had been handed off read-only (or for that matter, append-only, if it were a log file). So I guess we ought to just decide which behavior we want for lchmod() (really changes irrelevant symlink permissions vs refuses to follow or to operate on symlinks) and implement that (and the added chmod command option), and forget about flink(). When I had first mentioned lchmod() on comp.unix.solaris ages ago, ISTR some interest in it, and that distinction of functionality wasn't discussed. One of the reasons I said I wouldn't hand it out at the time was that the functionality of neither following nor operating on symlinks hadn't occurred to me then, and I didn't want archive files getting created with permissions that existing utilities (not using lchmod) wouldn't be able to restore. So the option of having it not alter symlink perms also has the attraction of not _requiring_ archive extracting utilities to use lchmod(). Although arguably they should, or better still, should use fchown() and fchmod() on the file just before closing it (so they can't be tricked into setting some other file by having their file deleted and a symlink substituted). And along those lines, it just occurred to me that a futimes(int fd, const struct timeval times[2]) call might also be handy to avoid shenanigans. I see that Linux and others have that, and some also have the analogous lutimes() as well. I expect that futimes() should enforce the same ownership, write access, or PRIV_FILE_OWNER checks as utimes() does. Or does the argument about a file descriptor handed off from a process that opened it in a directory the current process can't access also pose a problem with futimes()? It might allow doing something one couldn't previously, but at least it's restricted to those holding the file descriptor rather than anyone that might come along and access a path name later on (as with flink()). This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
