Re: Permission systems with ACLs
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?
bobstopper@australispro.com.au 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 -----
Reply to: