I sent this to the wrong address yesterday. Here it is again To answer your question, Tom, I think some form of database system would serve the purpose better. A flat file with everything just chucked onto the end would be horribly inefficient. A little extra time sorting a database during group updates would pay off for faster retreival times (which there would be plenty more of).
I don't know much about posix though. Would this fit into the posix model? Should we really care if it doesn't? :) Obviously we'd have to make it backwards compatible with current unix permission systems but given the nature of the solution that should be very easy to do. -- Forwarded mail -- Here you go. Sorry I didn't get this last night, I just checked my email now. I like what you suggest. Do you envision having entries in /etc/passwd or some other file stating where each user stores his/her user-defined groups? Or do you envision users having "append" access to /etc/group? [EMAIL PROTECTED] wrote: >>Ok, continuing with your example: I'm a plotter. The sysadmin gives all >>employees and board members access to set permissions on their own >>files, but not to create new groups. Furthermore, the sysadmin has more >>important things to do than make a group for people I trust. >> >>Hence the only way I can block the chairman is with a Deny ACE, or by >>removing the "Allow access to group board" ACE, and explicitly adding >>ACEs for all the plotters. >> >>True, this leaves me open to my adversary employing an agent. But >>creating a new group may not always be possible. >> >>Also, Deny ACEs become more interesting in the context of groups, I >>think, since they correspond to the set difference operation. For >>example, take the groups "Students" and "Untrusted Students". Using an >>Allow ACE for Students and a Deny ACE for Untrusted Students amounts to >>having an Allow ACE for the group "Trusted Students" (without explicitly >>creating this group). >> >>Perhaps the system could keep track of "Virtual Groups" somehow; that >>is, specify in some system file that "Trusted Students = Students - >>Untrusted Students". Then the group Trusted Students could be referred >>to, and would change automatically when Untrusted Students was changed. >>This would renden Deny ACEs unneccessary in the Group A - Group B case. >> >> > >How about a database of groups created by users. >eg not just >users >staff >adm > >but > >bob.friends >tom.trusted >fred.project_a > >Each user can set up their own groups. This avoids the messy problem of >only root having access to creating and manipulating groups. Furthermore, >it pretty much makes the idea of ACLs redundant. The "group" set of bits >can either be a system group, a user defined group or a single user that >can be specified > >ie > >-rwxrwx--- tom @adm .... >-rwxrwx--- tom @tom.friends .... >-rwxrwx--- tom george .... > >(The @ would probably be necessary to distinguish between users and groups >of the same name). > >I'm curious about why nobody's tried this before... is there something >wrong with the idea? > > > > > ----- End of forwarded message from Tom Hart -----
