Re: 2.4.8 Resource leaks + limits

[Jesse Pollard]

On Wed, 15 Aug 2001, Ingo Oeser wrote:
>On Wed, Aug 15, 2001 at 09:53:09AM -0700, Linus Torvalds wrote:
>> > For that to work we need to seperate struct user from the uid a little, or
>> > provide heirarchical pools (which seems overcomplex). Its common to want
>> > to take a group of users (eg the chemists) and give them a shared limit
>> > rather than per user limits
>> 
>> No, I think the answer there is to do all the same things for "struct
>> group" as we do for user.
> 
>Not really. Large installations use ACLs instead of groups. 
>
>Why? Because if we have 2^31 users, there might be a slight
>chance, that we need more then 32 group memberships per user.
>
>So let's better stop relying more and more on this group brain
>damage and start supporting ACLs. We can support building ACL
>groups, but please let the user and not the admin build them.
>
>It's called user data, because the user owns it and should
>decide, which people are allowed to access it. 
>
>Please look at AFS groups, to see what I mean.
>
>All serious admins I know miss the ACL feature in Linux. One
>product even emulates them via groups.

ACLs are good and very usefull.

HOWEVER, there are cases of users giving away their files to users
that are not authorized to recieve that data.

The advantage of groups is that the facility managment defines the
list of users authorized to view the data. It up to the user to
grant/deny that group access authorization.

Alternatively, it is possible to view the system as you describe - the
user can add others to the ACL to grant access. There should still be
some method that facility management can deny access.... On many systems
(Trusted Solaris, UNICOS, Trix,...) this is done with compartmentalization.
Now, it is subsets of the members of the compartment that the user can
grant access to.

Still more flexible than generic groups, but more restricted than no
limits on members of the ACL.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [e-mail]

Any opinions expressed are solely my own.