samba - Jun 2006 - Group permissions and recursion

Hi,

Now that we have successfully moved a first department share on to our 
mega SAMBA server, we're in the 20% of the old 80/20 rule.  Our problem 
has to do with group permissions within the extended acl.

We have implemented winbind along with the ADS security mode.  This 
means that a user isn't just "jdoe", but is
"MYDOMAIN\jdoe".  We are
using the extended ACL model which means that we can set specific 
permissions for specific security groups for access to any particular 
file.  The other thing I need to point out is that we have a hierarchy 
of security groups.  We have a security group, 'CATNET\adm' and the 
members of that security group are the security groups 'CATNET\adm 
staff' and 'CATNET\adm faculty'.  The members of the latter two
groups
are the actual users.

Here's the problem, a member of 'CATNET\adm staff' cannot access a
file
for which 'CATNET\adm' has r/w access (group:CATNET\134adm:rwx).  But if
I add 'CATNET\adm staff' even though 'CATNET\adm staff' is a
member of
'CATNET\adm', it works.  I thought this might be related to the smb.conf
parameter 'winbind nested groups', which I set to 'yes', but it
made no
difference.  Any ideas?

Thanks.


-- 

Rob Tanner
UNIX Services Manager
Linfield College, McMinnville OR

Rob Tanner wrote:
> Hi,
> 
> Now that we have successfully moved a first department share on to our
> mega SAMBA server, we're in the 20% of the old 80/20 rule.  Our problem
> has to do with group permissions within the extended acl.
I see this here too. Any hints you get would be greatly appreciated.

Thanks,
Graham

On Tue, Jun 27, 2006 at 10:49:04AM -0700, Rob Tanner
wrote:
> 
> Here's the problem, a member of 'CATNET\adm staff' cannot
access a file
> for which 'CATNET\adm' has r/w access (group:CATNET\134adm:rwx). 
But if
> I add 'CATNET\adm staff' even though 'CATNET\adm staff' is
a member of
> 'CATNET\adm', it works.  I thought this might be related to the
smb.conf
> parameter 'winbind nested groups', which I set to 'yes',
but it made no
> difference.  Any ideas?
Yes, that's got to be nested group evaluation not working
right. Try logging on as the specific user and then
calling the 'id' command to see what groups you're in.
They're the ones that winbindd is giving you (and the
same ones smbd will be using). From that you should be
able to start debugging why winbindd isn't giving the
full group list.

Jeremy.