From owner-freebsd-hackers Sun Jul 22 17:47:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 8391137B401; Sun, 22 Jul 2001 17:47:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA14180; Sun, 22 Jul 2001 17:47:28 -0700 (PDT) Message-ID: <3B5B7445.B945A7F5@mindspring.com> Date: Sun, 22 Jul 2001 17:48:05 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Joshua Goodall , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: <200107230016.UAA17001@renown.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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