If the kernel denies based upon an ACL (Unix side) then that's fine
with me. That's what Samba is supposed to do, is it not? The
user/group that the user "is" after authentication has just those
rights that the OS grants. If the ACL denies for group X then we
continue to try all the rest of the groups until either one succeeds
or we run out of groups. There is no need to check the ACLs in user =
space.

Consider: If I only have one group, the open() or whatever will either
succeed or fail. This can be because of "normal" Unix permissions or
POSIX ACLs. Adding another group changes nothing. The "quick and dirty"
method I proposed does nothing more than add an additional group
membership.

As to the "stupidly long" groups list there is of course the relatively
minor change of replacing all of the secondary groups with new entries
instead of just one at a time.


-----Original Message-----
From: Volker Lendecke [mailto:vlendec@sernet.de]On Behalf Of Volker
Lendecke
Sent: Dienstag, 8. M=E4rz 2005 14:53
To: Edgar, Bob
Cc: David Collier-Brown; samba-technical@lists.samba.org
Subject: Re: Dynamic groups (was Samba and groups > 16)


On Tue, Mar 08, 2005 at 02:03:34PM +0100, Edgar, Bob wrote:
> Forgive my naivety but what is wrong with the following:
>=20
> try to open/create the file/directory
> if EACCESS {
> foreach group in longlist {
> addgroup to groups list
> try to open/create the file/directory
> if success break
> }
> if failure return EACCESS
> }


Exactly this does not work. See my example in the posting you replied =
to.
The
kernel can *deny* your access based on a group membership. So you have =
to
replicate the kernel functionality for access controls completely in =
user
space. For each and every access that is access control sensitive.

Volker