Date: Sat, 17 Mar 2001 19:07:20 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: security@freebsd.org, Wes Peters <wes@softweyr.com>, Robert Watson <rwatson@freebsd.org>, fs@freebsd.org Subject: about common group & user ID space (PR kern/14584) Message-ID: <3AB3FC38.94711FFF@bellatlantic.net>
next in thread | raw e-mail | index | archive | help
All, I want to commit PR kern/14584. I've been told that it's good to discuss it in -arch, -security and -fs. (It has been sort of discussed on -hackers already, there were not much replies). So I've posted a message on -arch, and now on -security and -fs. I've also discussed this idea shortly with Kirk McKusick at Usenix-2000 at the BSD BOF and he generally liked it and suggested to review further. There is a rather long description in the PR. In short, the idea is that all the IDs above some value get shared by both users and groups. That is, not only two users can't have the same IDs (unless they are just aliases like root and toor) and two groups can't have the same ID, but an user and a group can't have the same ID as well. This allows to use the UID field in the inodes to give permissions in the unified UID&GID space, and thus give two groups (say, "writers" and "readers") different permissions to the file wtihout resorting to trickery with subdirectories. The ID space below this some value is kept separate for UIDs and GIDs for compatibility with the historic IDs. In the patch this feature is enabled by a kernel compilation option, plus even with this option compiled a sysctl has to be set. So it would not affect the unsuspecting users. Why not leave it to the real ACLs ? The problem I see with ACLs is that they break all the standard Unix commands dealing with displaying or storing the permissions, such as ls, tar, cpio and others of this sort. Probably the ACLs are _the_ way to go for the high-security environments. But from my personal experience with systems administration of HP-UX and NetWare in not-so-high-security environments, the careless application of ACLs tends to cause quite a systems administration nighmare. So I personally would avoid them for as long as possible and use only when really neccessary. And that seems to be not only my experience. For example, in UnixWare the ACLs were implemented and then essentially scrapped (never ported to VxFS and left working only as remnants in SFS, a version of FFS with ACLs which does not seem to be used by anyone any more and which may not be used as a root filesystem any more). This is the reason why I think that the classic Unix permissions still have a long live ahead, so some backwards-compatible extensions to them might be quite usable. Any comments are welcome. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB3FC38.94711FFF>