Date: Sun, 22 Jul 2001 17:48:05 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bakul Shah <bakul@bitblocks.com> Cc: Joshua Goodall <joshua@roughtrade.net>, Bruce Evans <bde@zeta.org.au>, freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks Message-ID: <3B5B7445.B945A7F5@mindspring.com> References: <200107230016.UAA17001@renown.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
> Well, I won't mind if {,l}ch{mod,own,flags} etc become library
> routines. Something like:
>
> int
> chown(const char* path, uid_t owner, gid_t group) {
> int fd, err;
>
> fd = open(path, O_EXCL);
> if (!fd)
> return errno;
> err = fchown(fd, owner, group);
> close(fd);
> return err;
> }
>
> But then you must be able to open() a symlink (O_NOFOLLOW
> flag must not make the open fail).
Can't be helped: some of the flags will make the write bit
fail, if they are set on the link and not on the target;
in fact, making the flags work on symlinks is really fraught
with peril, I think. It will give a false sense of security,
since even if the flags don't permit modification of the
link, the link target is up for grabs. Even if it were not,
you could always mount an FS over top of the FS containing
the link target... and it's still up for grabs, regardless
of the current security mode, so long as mounts are permited.
> My main argument is for consistent treatment and for `equal
> rights': if an object has an inode it must have the same
> rights as any other object also with an inode.
I normally agree with this -- not to mention symmetry for
the interface definitions alone. But the flags stuff is
getting out of hand, and really needs to be subsumed in the
ACL interface, instead.
> devfs is a different kind of beast just like msdosfs so
> rights of an inode based object are not the same as rights
> of devfs or msdos fs. Anyway, I argue for either adding a
> syscall or deleting a few to make a consistent set!
Deleting a few is reasonable -- and probably prudent.
> > If the chflags call was defined to always affect its
> > target (and not follow links), then the user space utility
> > could do the stat/readlink itself, and find the correct
> > target, if it wasn't told to not follow links.
>
> I don't like running namei twice. Between the stat/readlink
> and chflags(), things can change.
You're going to be running it twice, anyway -- and lose your
MAXPATHLEN agreement with the kernel, in the bargain, since
the link target is potentially expanded as a relative path,
and the way it's expanded is _not_ via recursion, it's via
expansion into the preexisting pathname buffer.
> [Digressing a bit...]
> Ideally I want only the f* version of syscalls, so that you
> _have_ to `open' an object. Open gives you a handle, a
> 'capability' to operate on the object. In the past I have
> argued for *always* passing in a capability even for open().
> Then you can throw away even the chdir() call. But then
> it won't be the unix we know and love and hate!
I'm not that sure; I've always advocated that the POSIX
interface belongs in the C library, and if the system itself
happens to also have those semantics, OK, but if it does not,
well, then OK again.
There's a lot of value in having all the normal file calls
return stat information, if there is a buffer provided to do
the job, since user space file services for PC's and even
Macintosh's end up wanting the moral equivalent of stat
information on directory iteration, file open, reads, writes,
file closes, etc. (see SAMBA or CAP). You can generally get
a 30% improvement in file server latency by returning this in
the cases it's needed, and halving the number of system calls.
-- 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?3B5B7445.B945A7F5>