Question Need for 'module' installed in 3.6.0-rc2

[Linda W]

Volker Lendecke wrote:
> 
> I have definitely seen this in 2.6 kernels. You have to
> exactly follow the steps described in the bug. If I remember
> correctly it only happens if you create a directory using
> your rights from a group acl entry (or something like that).
> If you are doing it as the owner of the parent directory it
> does not happen. It was something very specific, look at the
> bug.
-----
	I see now...  But this appears to be correct functioning.


The user is using the command:
    dir is owned by me and I'm NOT in the group it is setGID to, then I:
chacl  -b u::rwx,g::rwx,g:lawgroup:rwx,o::---,m::rwx u::rwx,g::rwx,g:lawgroup:rwx,o::---,m::rwx  dirname

That breaks down to the object's perms and defaults for contained objects.

I.e, set basis umask to u+rwx,g+rws,o-rwx  for the object and its contained
objects, + an extra entry for 'lawgroup'.

If I **wasn't** in the group that owned the file -- I've just changed the
security about who can read, write or search in that dir.  Thus, I may have give
read access (maybe it was write only so people could leave logs), or I've added 
write access -- it was set to read only because other children, had been created
with writable access under the same GID, then the parent dir had been changed
by someone in the group to no-write.


Either way, _I_, who am not in the group, should not be able to 'set' the security
on the group perms without clearing the SGID bit.

However, if I am IN the group, the bit doesn't get cleared, as being 'of' the group
it wouldn't be a security leak.


So...let me get this straight...

Are you saying samba has a module to override this functionality and thereby
introduces the security leak I described?



Or am I still confused?

(Likely, but just checking...)...