Date: Sat, 10 Jul 1999 22:04:13 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: hackers@freebsd.org Subject: Proposed substitution for ACLs Message-ID: <3787FB9D.3CDF0839@bellatlantic.net>
next in thread | raw e-mail | index | archive | help
Hi! I want to propose a simple substitution for ACLs. No, here is no patch yet but I'm ready and willing to do it. The reason why I want to discuss it first is that this is a Political Thing. And if the Core Team decides that it's a Bad Thing, I suppose it will never get commited to the system. Because of this I would like to see some encouraging signs from the Core Team before implementing it. Now to the issue itself. ACLs are a popular thing nowadays and as far as I know FreeBSD does not have it yet. But although everyone boasts with their ACL support I think nobody is really using it (and if somebody is using it then I think it's often not the best decision). ACLs have obvious drawbacks: - they are not supported by the standard file formats like tar or cpio - they need lots of ugly flags for the commands like chown or ls, and some new ugly commands - they are just by themselves difficult to show clearly in ls - they are a mess and promote ad-hoc assignment of permissions For example, Netware suports ACLs and I have seen by myself what mess the sysadmins who have head problems are able to create with them. But in fact the classic Unix permissions seem to have only one real problem: sometimes it's neccessary to give read permissions to one group of users and read-write permissions to another group of users. But Unix permissions support permissions for only one group and that makes the problem. A simple solution would be to add the second group but this would also break the compatibility. I propose to re-use the "uid" field to held the permissions for the second group. Suppose we do the following: 1. Add a sysctl flag enabling or disabling (by default) the extended permissions. That should completely cover the compatibility issues. 2. Sysadmin uses unique IDs for the users and groups in the common ID space. Say, if there is a user with ID=2000 then there must be no group with ID=2000 (except a special case described later). Traditionally there is such overlapping in the low IDs, so let's enable the new behavior only for IDs > 1000 (or some other number, possibly another sysctl parameter). 3. Implement the following semantics (a simple and straightforward addition to ufs_access() ): if the new behavior is enabled and the file owner's ID is over 1000 (or a sysctl parameter) then in addition to comparing the process'es UID with the file owner ID we compare all process'es group IDs with the file owner ID and if any of them matches we use the "owner" permissions for this process. So, in effect we consider the file owner ID as both user and group number, and the described problem with two groups with different permissions is solved. 4. The described semantics is used only for file access but not modification of the access rights, the "owner group" can't modify the permissions of the file. And here we come to the special case mentioned in p.2: if there is an user with UID equal to the GID of the "owner group" such user can modify the permissions. This user may be a pseudo-user created together with the group. If we want to give the "owner group" the right to change all permissions of its files we can just do something like (suppose whe have user `mygrp' and group `mygrp' with the same ID): # cp /bin/chmod /usr/local/bin/mygrpchmod # chown mygrp /usr/local/bin/mygrpchmod # chmod 500 /usr/local/bin/mygrpchmod # chmod u+s /usr/local/bin/mygrpchmod The same thing may be ised for chown. In result all the group members will be able to execute mygrpchmod, and when it will be executed it will assume the EUID of the user mygrp and will be able the file permissions. Or we can do `chmod 050' and give the permission to modify all the permissions of this "owner group" to another group of users. Having a pseudo-user with the same ID as a group also gives for free `ls' showing the right symbolic owner name. 5. If this behavior is wanted on NFS, that can be done too. Probably, with a separate sysctl flag. These additions give essentially the same flexibility as ACLs give but without any change in the i-node format, ls and tar/cpio formats, don't really need any special programs nor flags to manipulate them. Though a few user-level additions may be added for convenience, such as automatic addition of a pseudo-user for each defined group, check for user/group ID conflicts, multi-level groups, additional programs to give better granularity of control over file permissions. That's all. I think the idea is rather simple and clean. Any comments are welcome. -SB 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?3787FB9D.3CDF0839>