[lkml]   [1999]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ext3 filesystem info?
On Wed, 22 Sep 1999, Steve Dodd wrote:

> On Wed, Sep 22, 1999 at 10:36:54AM -0400, Stefan Monnier wrote:
> > > That's a userspace thang though, not a kernel problem.
> > It seems that way, but it's not just a user-space problem because
> > allowing users to create their own groups and to add people to them
> > poses problems with the NGROUPS limit, unless you somehow manage to
> > restrict the interface so that users can only add themselves to groups.
> So instead of login loading all the groups blindly, have it AND the
> list of groups the user is allowed to be in (/etc/group or whatever entries
> listing the user) with a list the user has declared she wants to be in,
> stored in ~/.group or similar.. Maybe have a su-like program to spawn a shell

This is a pure userspace and login issue. Problems will arise from ftp or
other services authenticating you though, because ftpd would also need to
know as which group member to do file access. It could use ~/.group as
well or use some site specific FTP extension, again a user space issue.

I still won't suggest anyone to do it as it is pretty non standard.

With regards to NGROUPS, I'm sure it can be easily raised. It might be
possible to handle it fully dynamic, but you still want to have a hard
limit to stop a gone mad process to be in a set of almost 2^32 groups.
Also there is a performance issue, any file access will have to loop
through the list of groups to determine if you have access or not, so you
want to keep the list small. If longs lists of group were allowed I'm sure
one can optimize this with a binary search in a sorted list of groups, but
this won't help much in conjunction with ACL's then.

Anyway, I'm pretty sure there is a misunderstanding here. What the
original poster said had nothing to do with a unix group:

> > allowing users to create their own groups and to add people to them
> > poses problems with the NGROUPS limit, unless you somehow manage to

Under no Unix variant I know are users allowed to add/create an own group
where to be in.

However, consider users A and B, A in group GA and B in GB but in no
other common group where user A wants to give access to a file/directory
to user B. Or if they are in a group GC, there are other users there which
must not get access. Also, it is not desirable to make that file/directory
world readable (not to speak of writing).

Now, with acl's, user A can just give access to user B. And even to user C
and D and... . So with acl's, any 'set' of users can define kind of a
virtual group by electing some 'group leader' who creates a file/dir and
gives the other users access to it. NGROUPS or /etc/groups or any root
intervention is not required. There might/will be a limit on the number of
acl rules per file though.

Without acl's you can only do this with the admin creating and managing
the group, and you'll hit the NGROUPS limit when there are many, non
disjunct groups.

So, acls are a nice thing for users which are not admins that want to
share files beyond the rather simplistic group structure of Unix.

Now, the admin might actually not want users to share such info for
whatever reason. So, there are possible security issues. Also, things are
far more complex to review if any user can give access to anyone through
acls. The acls are not seen directly with ls and are seperate on a file
basis, so it is surely a pain to audit, if you want/need to audit it. And
not being able to audit it easily might be a security issue. Like: there
is a suid root executable with unix permissions "rws------" but an acl
allows 'nobody' to exec it (and exploit a bug) but you don't easily notice



Michael Weller:,,
or even If you encounter an eowmob account on
any machine in the net, it's very likely it's me.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.051 / U:0.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site