Date: Thu, 25 Jun 1998 14:23:26 -0300 (ARST) From: "Fernando P. Schapachnik" <fpscha@localhost.schapachnik.com.ar> To: security@FreeBSD.ORG Subject: Re: adduser chmod... Message-ID: <199806251723.OAA00260@localhost.schapachnik.com.ar>
next in thread | raw e-mail | index | archive | help
I think that BSD semantics for groups are fine but not perfect. For example: what happens is userA has some he whishes to share with userB and userC but not userD, and some others he whishes to share just with userD and userE? He has to ask sysadmin to make to groups just for him! An interesting approach would be having /etc/group and $HOME/.group. In that context a file owned by userA:group1 would mean "The owner of this file is userA, and the group is group1, whose members are those specified in /etc/group is group1 exists in that file, or the ones specified in ~userA/.group in another case". This schema will let users have as many groups as they wish and administer them without setuid programs. Another very interesting feature would be the possibility to have in $HOME/.group something like: my_family:*:~daddy meaning that the users who belong to this group are listed in daddy's group my_family. The purpose of this is to allow a group of user to stablish a "workgroup" and let just one of them be the maintainer. Two problems arise: 1) How to guarantee unicity between users' groups and -let's call them this way- /etc groups? A simple approach would be that a user group is considered invalid if it has the same name that a system group. In this case the groups behavior is like the empty group (ie, no user belogs to that group). When a user wants to stablish a new groups he just must check against /etc/group (a script can do this for him). What happens when root adds a new group, said group1. Well, existing users will have their own group1 behave like the empty group. But this shouldn't be a problem because we can have a daily scripts that whenevers finds /etc/group has been modified compares system groups against user groups and mails the affected users. An userland script could be provided to simplify "change all my the files that belong to group oldgroup to newgroup". 2) How to guarantee gid's unicity? This is the hardest part. Perhaps changid gid_t to long it and allowing a fixed number of groups per user? Something like it would mean that although saying "file A group is group1" is ambiguous, the ambiguity disappears once you get the gid, that's still unique. Most programs shouldn't note the change. Another posibility is that gid only makes sense knowing the uid. I particulary don't like it because means breaking a lot of software. Just an opinion ;-) Regards! Fernando P. Schapachnik fpscha@schapachnik.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806251723.OAA00260>