Group permission issues

[David Collier-Brown]

If you're not using Linux, you can easily get caught with not enough
groups. Try this
experiment:

on the SGI server, find one of the users who failed
$ su root -c " id user"
where user is the name or uid of the user in question
look and see if 15007 appears in the group list.

If it does, there's a Samba problem
If not, we have a Unix problem

--dave
Ron Short wrote:
> David,
>
> thanks
>
> The Samba server software is running on an SGI system using the SGI
> "enhanced" version of the Samba software.  If we need to, we can try
> using the Samba distribution provided in the SLES distribution.
>
> David Collier-Brown wrote:
>> Ron Short wrote:
>>   
>>> 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   
>>>     
>> Ok, that makes sense, is the Samba server itself on Linux? If so it's a
>> new bug, and probably
>> a regression (;-))
>>
>> If it's on an SGI, it's an old bug for which the alternatives are
>> - fix an SGI bug (preferred)
>> - use ACLs
>> - work around it via an interposer library I just updated.
>>
>> The SGI fix is substantially the same code as in the interposer.
>>
>> --dave
>>
>>   
>
> -- 
> Ron Short                                       email: short at sgi.com
> Solutions Architect                             office: 651/683-5680
> SGI Global Professional Services                fax: 651/683-5288   


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968