Group permission issues

[David Collier-Brown]

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

-- 
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