Date: Sun, 22 Jul 2001 15:11:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Joshua Goodall <joshua@roughtrade.net> Cc: Bakul Shah <bakul@bitblocks.com>, Bruce Evans <bde@zeta.org.au>, freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks Message-ID: <3B5B4F7E.8C48801E@mindspring.com> References: <Pine.LNX.4.33.0107222216530.4671-100000@elm.phenome.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Joshua Goodall wrote: > Possibly, but shouldn't we be wary of changing syscall semantics? > Especially in code that relates to securelevels. Pretty much no one uses these calls directly; a grep of the source tree showed only three programs; the default behaviour of the call can be changed safely, if these programs are changed to do the link following in user space, and the man page is updated. > I guess there is general agreement that it is desirable to be able to set > schg,sunlink etc on symlinks and fifos. Probably devices, too, which is a can of worms, particularly with devfs. Already, the fchown/fchmod on sockets and other things which use a non VFS struct fileops fails -- I think this includes FIFO's. > The consistency argument goes like this: > > Currently exposed as accessor methods to VOP_SETATTR are: > chmod(2), fchmod(2), lchmod(2) > chown(2), fchown(2), lchown(2) > chflags(2), fchflags(2) I know the argument for adding more and more system calls; I just don't agree with it. BSDI has already suggested limiting the total number of FreeBSD system calls to something like less than 32 more, total, without going to another block much higher up, and having to have FreeBSD allocate a large, sparse system call array, adding potentially a lot of overhead, depending on future directions with the ABI. In other words: they are getting to be scarce resources. Also note that this will introduce a binary backward compatability problem for the three programs which use the system call, in any case, but in your approach, the programs core dump on an ENOSYS, instead of failing more gracefully. This is sort of like the 5.x mount command, which will cause a 4.x system to panic. Imagine updating, and needing to boot kernel.old. > History records that the semantics for following symlinks in > chown & chmod date from 4.4BSD. Yes. It's a nasty POSIX thing, very much like the nasty POSIX thing of deleting all locks when you have multiple open file instances, and close only one of them. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B5B4F7E.8C48801E>