Bug 6350 - Strange behavior when two groupmap entries maps to the same unix group
Summary: Strange behavior when two groupmap entries maps to the same unix group
Status: NEW
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: User & Group Accounts (show other bugs)
Version: 3.2.5
Hardware: x86 Linux
: P3 minor
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 06:12 UTC by Sascha Herrmann
Modified: 2010-08-30 10:05 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Herrmann 2009-05-12 06:12:40 UTC
I had some issues here because we had a duplicate groupmap entry pointing to the same Unix group, which caused that user couldn't delete files using samba which they had correct unix permission to (Directory permissions set to 0775 and user was member of the directories group). With "acl check permission = false" the problem didn't occur.

"net groupmap list" returned the following:
Domain Users (S-1-5-21-1620896164-3410292537-1148934433-513) -> users
user (S-1-5-21-1620896164-3410292537-1148934433-1201) -> users

Group users has the gid 100.

When deleting a file with log level 10 I got the following log:
===========================
[2009/05/11 15:46:40,  3] lib/util_seaccess.c:se_access_check(252)
  se_access_check: user sid is S-1-22-1-1355
  se_access_check: also S-1-22-2-100
  se_access_check: also S-1-1-0
  se_access_check: also S-1-5-2
  se_access_check: also S-1-5-11
  se_access_check: also S-1-22-2-809
  se_access_check: also S-1-22-2-806
  se_access_check: also S-1-22-2-5555
  se_access_check: ACE 0: type 0, flags = 0x00, SID = S-1-22-1-1000 mask = 1f01ff, current desired = 2
  se_access_check: ACE 1: type 0, flags = 0x00, SID = S-1-5-21-1620896164-3410292537-1148934433-1201 mask = 1f01ff, current desired = 2
  se_access_check: ACE 2: type 0, flags = 0x00, SID = S-1-1-0 mask = 1200a9, current desired = 2
[2009/05/11 15:46:40,  5] lib/util_seaccess.c:se_access_check(316)
  se_access_check: access (2) denied.
[2009/05/11 15:46:40, 10] smbd/open.c:create_file_unixpath(2893)
  create_file_unixpath: NT_STATUS_ACCESS_DENIED
===========================

The user is member of the group users (which was mapped to S-1-22-2-100). But the group of the directory was mapped to the entry from the groupmap table, causing sambe to deny access to delete the file...

After removing the duplicate entry from the groupmap things works as expected:
================================================
[2009/05/12 11:14:58,  3] lib/util_seaccess.c:se_access_check(252)
  se_access_check: user sid is S-1-22-1-1355
  se_access_check: also S-1-5-21-1620896164-3410292537-1148934433-513
  se_access_check: also S-1-1-0
  se_access_check: also S-1-5-2
  se_access_check: also S-1-5-11
  se_access_check: also S-1-22-2-809
  se_access_check: also S-1-22-2-806
  se_access_check: also S-1-22-2-5555
  se_access_check: also S-1-22-2-100
  se_access_check: ACE 0: type 0, flags = 0x00, SID = S-1-22-1-0 mask = 1f01ff, current desired = 2
  se_access_check: ACE 1: type 0, flags = 0x00, SID = S-1-5-21-1620896164-3410292537-1148934433-513 mask = 1f01ff, current desired = 2
[2009/05/12 11:14:58,  5] lib/util_seaccess.c:se_access_check(310)
  se_access_check: access (2) granted.
================================================

Now the group gets mapped to S-1-22-2-100 and the group from the groupmap, which matches the group of the ACE.

Since I wasn't able to re-add the duplicate entry to the groupmap I think the Samba database was somewhat corrupted here!?! Maybe Samba or testparm should write some descriptive warnings to the logs when such an situation is detected.

The Samba-Server is a member of a Win2000 Domain but winbind isn't used. The setup has received several setups in the past (started from samba 2.x.x), which may be the reason for some corrupt entries in the database...
Comment 1 Volker Lendecke 2010-08-30 10:05:48 UTC
Michael, afaik you're working on a tool that checks the validity of the idmapping database. This should print out problems like this, right?

Assigning to you, you might want to update this bug when that tool is done.

Thanks,

Volker