From owner-freebsd-hackers Sun Jul 22 17:23:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by hub.freebsd.org (Postfix) with ESMTP id B6ACD37B405; Sun, 22 Jul 2001 17:23:41 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by renown.cnchost.com id UAA17001; Sun, 22 Jul 2001 20:16:11 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107230016.UAA17001@renown.cnchost.com> To: tlambert2@mindspring.com Cc: Joshua Goodall , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks In-reply-to: Your message of "Sun, 22 Jul 2001 15:11:10 PDT." <3B5B4F7E.8C48801E@mindspring.com> Date: Sun, 22 Jul 2001 17:16:11 -0700 From: Bakul Shah 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 > > 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. 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). 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. 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! Earlier you said: > 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. [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! -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message