Group permission issues

[Ron Short]

David,

A basic test case that fails.

User test user belongs to the ad domain domain users group which maps to 
uid 15004 on the samba server.
The user also belongs to other groups for example, the NMCS\uploadwip 
group gid 15007

They create a directory on the samba server called 6200 and it has 
permissions:

owner a user called filemanager and group NMCS/uploadwip ie. 15007.

Users that are members of group 15007 but where it is not their primary 
group get access denied attempting to write to the directory.

just to clarify, are you
talking about primary group working and
supplementary groups failing, where access is controlled by giving
permission to a group which is in the
supplementary groups list of a user?

Yes,

David Collier-Brown wrote:
> Ron Short wrote:
>   
>> We have an issue with subgroups in that permission information does
>> not seem to be forwarded to Windows Samba Clients. Basically the
>> primary application runs with some higher privilege level of
>> permission above the normal user rights. They can't get the permission
>> through the subgroups thus the application breaks.
>>
>> sdathengmds01:~ # cat /etc/*release
>> SUSE Linux Enterprise Server 10 (x86_64)
>> VERSION = 10
>> PATCHLEVEL = 2
>> LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-x86_64:core-3.0-x86_64"
>>
>> SGI Foundation Software 1SP3, Build 603r4-0903312302
>> SGI InfiniteStorage Software Platform, version 1.6, Build
>> sgi160r2-1.6, Wed Apr  1 19:00:40 UTC 2009
>> SGI ProPack 6SP3 for Linux, Build 603r4-0903312302
>> SGI ProPack 6SP3 for Linux, Build 603r4-0903312302
>>
>> sdathengmds01:~ # rpm -q -f /usr/sbin/smbd
>> sgi-samba-3.2.0-24.1sgi160r2
>> sdathengmds01:~ #
>>
>> smb.conf file
>>
>> sdathengmds01:~ # more /etc/samba/smb.conf
>>
>> # Global parameters
>> [global]
>>        workgroup = NMCS
>>        realm = NMCS.SDMENGINEERING.COM
>>        netbios name = ENGSMB
>>        name resolve order = lmhosts host wins bcast
>>        interfaces = 162.49.57.25/0xffffff00
>>        bind interfaces only = Yes
>>        security = ADS
>>        auth methods = winbind
>>        password server = dmcontroller2.nmcs.sdmengineering.com,
>> dmcontroller3.n
>> mcs.sdmengineering.com
>>        #passwd program = /usr/bin/passwd %u
>>        #passwd chat = *ew*password:* %n\n *e-enter*new*password:* %n\n
>>        max log size = 500
>>        max xmit = 65535
>>        os level = 0
>>        preferred master = No
>>        local master = No
>>        domain master = No
>>        ldap ssl = no
>>        idmap uid = 15000-20000
>>        idmap gid = 15000-20000
>>        comment = %h (Samba %v)
>>        hosts allow = 162.49.57.
>>        hide dot files = No
>>        locking = No
>>        share modes = No
>>
>> [library]
>>        path = /media/library
>>        read only = No
>>        directory mask = 0775
>>        #force group = +dmfwrite
>> [cam]
>>        path = /media2/cam
>>        read only = No
>>        directory mask = 0775
>>        #force group = +dmfwrite
>>
>>
>>     
> Jeremy already asked for more information, but, just to clarify, are you
> talking about primary group working and
> supplementary groups failing, where access is controlled by giving
> permission to a group which is in the
> supplementary groups list of a user?
>
> If so, there is a known problem with non-Linux Sambas and having more than
> 16 or 32  supplementary groups. Might this be what you're seeing on an
> SGI, or is
> this a purely Linux regression?
>
> --dave
>
>
>   

-- 
Ron Short                                       email: short at sgi.com
Solutions Architect                             office: 651/683-5680
SGI Global Professional Services                fax: 651/683-5288