Group permission issues - looks like Samba is not getting them
David Collier-Brown
davec-b at rogers.com
Fri Aug 14 13:16:14 MDT 2009
Pardon the top-posting, but Ron and I did an experiment with one of the
users, and id said that
- the user only had 4 groups
- none of them were NMCS\uploadwip group, gid 15007
The NMCS\uploadwip in AD isn't reaching the system, at least as far as
/usr/bin/id can tell, and as a result is being denied access to
files with group 15007.
Looks like a regression of some sort ...
--dave
id=6010(eftmanager) gid=3011(eftwrite)
groups=3011(eftwrite),3004(fileadmin),3007(idgwrite),3008(idgread)
NMCS\uploadwip
group gid 15007
David Collier-Brown wrote:
> 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
More information about the samba-technical
mailing list