FW: Speed comp. TNG & 2.2.alpha (fwd)

[Andrew Bartlett]

Steve Langasek wrote:
> 
> On Tue, 27 Feb 2001, Peter Samuelson wrote:
> > 
> > I think I sort of like Andrew's proposal better -- ignore the duplicate
> > group names entirely w/r/t sending and receiving security descriptor
> > information.  (NT doesn't require it, since unlike Unix it doesn't
> > assume that every file has a group.)  If the client wants to change the
> > ACL of a file to have no groups in it, you can use the default
> > nobody-group ('nogroup' on my Linux box).
> 
> How do you decide generally which group names should be ignored?  I can
> certainly think of cases where I might have a file whose gid maps to a group
> that conflicts with a username and I /do/ want to show the group in the file
> permissions...
> 
> Steve Langasek
> postmodern programmer

This discussion started on matters of O(n^3) complexity - I was thinking
that if users and their private groups were treated as one, including
system groups using the same scheme - that this could help reduce 'n',
even if we are stuck with an O(n^3) algorithm.  

The way to tell if a group is a private group is fairly simple - a
simple getgrnam call tells you if there are any non-primary members, and
if it is the same name as the user, and particularly if its gid is the
same as the user's uid then the odds are pretty good that its a private
group.  A final check would be if no other users have this as their
primary gid.  The results of these checks could be cached for a short
period of time - as the answer (true/false, this is a primary group)
isn't likely to change often.  The number of checks could be configured
by the admin, as they should know how they arranged their system.

If you do have a user/group name clash, then and only then do you need
to look into name-space issues - some installations might get away with
it altogether, I know mine would.

This way the security descriptor would not show the group, and if users
are looked up before groups, then this should remove some of the
complexity from the whole operation.

In any case, it would be good to get a list of all groups on a system
and not see all the private groups setup for each individual user when
all I want to see is admins, staff and students - if you see what I
mean.  This would also knock out many of the 'system' groups in the
process, as they exist only because they don't want to run as 'nogroup'
- they are just private groups for that particular system daemon.

On an implementation level, the reverse can be also be applied:  If a
user removes all group permissions on a file (thereby leaving it
groupless) it can simply be changed back to that users primary (often
private) group - or even nogroup, with group mode 0 if necessary.  This
would then be relayed back to NT to look as expected - this file has no
group permissions.

Or am I just talking through my hat?
Andrew Bartlett

-- 
Andrew Bartlett
abartlet at pcug.org.au