Bug 4348 - UNIX groups not honoured for access to filesystem
UNIX groups not honoured for access to filesystem
Product: Samba 3.0
Classification: Unclassified
Component: winbind
Sparc Solaris
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2007-01-19 12:29 UTC by David Pullman (DSN code 5.1.1)
Modified: 2014-07-23 21:32 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Pullman (DSN code 5.1.1) 2007-01-19 12:29:08 UTC
Copies of emails sent to samba-general:

We have what may be a very, very bad situation here and I'm hoping someone may be able to point out either where I'm misinterpreting this or where I missed the memo.

We're testing 3.0.23d so we can upgrade from 3.0.14a.  Our servers are all currently Solaris 9, and we build samba from source with MIT krb5 and openldap libraries.  We have used security = ads since 3.0 after having used security = domain with nt4.0 for many years in the 2.2 era.

We also have winbindd running, but only with idmap to an ldap directory to map uids to sids.  All usernames are in NIS and the identical usernames are in AD, as they were in NT before.  We share all directories to both NFS and CIFS clients, with posix acls on the file server.  This has worked for years.  We only pursued the winbindd feature for idmapping to provide the users with the ability to add a name to an acl in Windows.  Currently on 3.0.14a this works fine.

We do not have unix groups, as populated in NIS group, in the AD.  We do not use winbind for any authentication.

When we started testing 3.0.23d we found that the primary group of a user seemed to be honored for access to a file or directory, but the secondary groups were not.  On our test server I cranked up idmap and auth logging.  Then we added some group names to AD; this was after I asked Gerry at the LISA conference about the issue I was seeing.

In the log snip below the server is getting a bunch of sids for my login.  Everyone of these is only the groups that are enumerated on AD, specifically with my name in the group.  Also, in trying to access folders on a share, only the groups listed will allow permission; if I have a group on a directory that I'm a member of in UNIX but not in AD I can't access the folder.  ****This is different than it used to be****

[2007/01/11 11:08:40, 10] auth/auth_util.c:(454)
  NT user token of user S-1-5-21-1214440339-839522115-1708537768-1623
  contains 9 SIDs
  SID[  0]: S-1-5-21-1214440339-839522115-1708537768-1623
  SID[  1]: S-1-5-21-1214440339-839522115-1708537768-6843
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-1214440339-839522115-1708537768-2254
  SID[  6]: S-1-5-21-1214440339-839522115-1708537768-513
  SID[  7]: S-1-5-21-1214440339-839522115-1708537768-2270
  SID[  8]: S-1-5-32-545
  SE_PRIV  0x0 0x0 0x0 0x0

[root@chrome boogie]$ wbinfo -s S-1-5-21-1214440339-839522115-1708537768-6280
MELAD\tac 2
[root@chrome boogie]$ wbinfo -s S-1-5-21-1214440339-839522115-1708537768-2270
MELAD\melsa 2
[root@chrome boogie]$ wbinfo -s S-1-5-21-1214440339-839522115-1708537768-2254
[root@chrome boogie]$ wbinfo -s S-1-5-21-1214440339-839522115-1708537768-6843
MELAD\wwwmel 2

Taking this a step farther:  we added a UNIX group to AD and put my name in it.  I am not a member of this group in UNIX.  In the snip below that sid is now included in my user token.

[2007/01/11 11:34:53, 10] auth/auth_util.c:(454)
  NT user token of user S-1-5-21-1214440339-839522115-1708537768-1623
  contains 11 SIDs
  SID[  0]: S-1-5-21-1214440339-839522115-1708537768-1623
  SID[  1]: S-1-5-21-1214440339-839522115-1708537768-6843
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-1214440339-839522115-1708537768-2254
  SID[  6]: S-1-5-21-1214440339-839522115-1708537768-513
  SID[  7]: S-1-5-21-1214440339-839522115-1708537768-6279
  SID[  8]: S-1-5-21-1214440339-839522115-1708537768-2270
  SID[  9]: S-1-5-21-1214440339-839522115-1708537768-6280
  SID[ 10]: S-1-5-32-545
  SE_PRIV  0x0 0x0 0x0 0x0

With this token I was able to create files and directories in a directory that had this new group.  I'm not the owner of the directory, or a member of the group, and other has only r-x. ****Even though I am not permitted to do this in UNIX****

[root@chrome testing]$ ls -al .
total 8
drwxrwsr-x   4 carolyn  adacs        512 Jan 11 11:35 .
drwxr-xr-x   8 root     sys          512 Jan  5 13:37 ..
drwxr-sr-x   2 dpullman adacs        512 Jan 11 11:35 New Folder
[root@chrome testing]$ groups dpullman
melsaunx wwwmel melsa gss gssreq office root sensor lp melsapw sa webgroup admin tac

Isn't there a statement somewhere that samba will honor the UNIX permissions?  How am I able to write in a directory that I do not have access to according to the UNIX permissions?

Is it the intention of the samba development that all UNIX groups will have to not only be listed in AD, but also populated?

Thanks very much. 

In some subsequent testing it seems to be in winbind: by commenting out the ldap, idmap, and winbind params in smb.conf and not starting winbindd, the authorization is as expected:

When I access the share, I get the slew of groups  that I belong to in UNIX mapped to the S-1-22 sid:
[2007/01/11 18:59:56, 10] auth/auth_util.c:(454)
  NT user token of user S-1-22-1-19122
  contains 18 SIDs
  SID[  0]: S-1-22-1-19122
  SID[  1]: S-1-22-2-4228
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-22-2-3001
  SID[  6]: S-1-22-2-4227
  SID[  7]: S-1-22-2-4031
  SID[  8]: S-1-22-2-4128
  SID[  9]: S-1-22-2-4023
  SID[ 10]: S-1-22-2-0
  SID[ 11]: S-1-22-2-19029
  SID[ 12]: S-1-22-2-8
  SID[ 13]: S-1-22-2-4229
  SID[ 14]: S-1-22-2-304
  SID[ 15]: S-1-22-2-400
  SID[ 16]: S-1-22-2-80
  SID[ 17]: S-1-22-2-4260
  SE_PRIV  0x0 0x0 0x0 0x0

And with the UNIX group that I'm not a member in place on the directory, I cannot create files or directories.  If I change the group to one of my secondary directories, I have rwx as expected.

Of course, without winbind and idmapping, the Windows ACL shows "Unix User" and "Unix Group" for domain on the entries, and of course there is no ability to add to the ACL, as we are currently doing in 3.0.14ap (attempting to add a username):
[2007/01/11 19:15:29, 0] smbd/posix_acls.c:(1399)
  create_canon_ace_lists: unable to map SID S-1-5-21-1214440339-839522115-1708537768-1219 to uid or gid.

Is the authorization issue I've outlined with winbind and idmap running a bug, or a misconfiguration, or is the functionality not supported where Samba is going?  It seems like the old days of "Samba is a file server" is going by the wayside in the pursuit of AD/Domain Controller functionality.  I have to admit that I don't follow all the mailing lists topics as closely as I would like; we're spread too thin.  So as I said, if I missed the memo, please let me know :)
Comment 1 Ben Enser 2008-04-02 09:14:39 UTC
I believe am experiencing the same problem.

Hardware: x86 (Intel Xeon)
Samba version: 3.0.25b-1.el5_1.4
OS: Linux (Centos 5)

I have successfully configured Samba to use Winbind to authenticate users against our AD domain.  However, we've noticed the same behavior described above.

winbind_use_default_domain is set to "yes"  We use the shorter username in all circumstances however I believe Windows is passing the fully qualified user name (ie. DOMAIN\\username) when connecting from remote.

We're not mapping any users or groups.  None of the user accounts we're dealing with are local unix accounts; they all come from the domain.

How I reproduce the problem:
Create any local unix group (I'll use "group1"), add a user from the domain to it (I'll use "user1".  We do have winbind_use_default_domain set to true so we've been adding the username alone to the /etc/group file.

Grant group rwx to a directory or file (one that is shared on the network) for the group1 group, make sure the user you're going to attempt to use the file from does NOT own the file (in my case, "user1" must only be a member of the group that has privileges to it but may not own the file: if "user1" owns the file, things work as expected).  If logged into ssh, "user1" can read/write to the file in question without problems.  When attempting to access the file from my windows system via the share, the same user will NOT have read/write access.

If the group in question is a domain group (for example "domain users" instead of "group1"), the shares behave as expected.

Another thing I noticed: output of:
# groups MYDOMAIN+user1

does not match the output of:

# groups user1

I too am interested if this is the intended behavior or if something broken.  My inclination is to suggest that it's broken as the share does not behave in the same manner as the same user account logged in to a shell and furthermore, MYDOMAIN+user1 and user1 should be members same groups: they're technically the same user.
Comment 2 Björn Jacke 2014-07-23 21:32:47 UTC
users get their group memberships assigned by AD and the unix group membersips are not being asked. This is by design. A hack that currently works is to trick Samba by mapping the incoming user to "another" user which triggers a different, less accurate code path. set "username map script = /bin/echo" if you really want to use group memberships from nss. But this is not a recommended thing to do generally...