Steps to reproduce: 1) Join a AD (disney, in my tests) 2) Add a share Test (wg|ad)sharetest 3) restricts the access to the share for two AD users (i.e. disney\user_001 and disney\user_002) 4) using disney\user_001 on windows 7 through windows explorer, create a file called file1.txt inside the share Test and access the security settings. Select Allow All for user_001 and deny all for user_002 5) using disney\user_002 try to open file1.txt. Actual results: The file will be opened as user_002 had access to it. Expected Results: In fact it does through the "Everyone" and "Domain users" groups, but as disney\user_002's access is explicitly set to deny, the access shouldn't be allowed. Additional info: If we do the same using workgroup instead of AD (using wguser1 and wguser2), the access will be denied correctly for wgsharetest. This ACL seems to be broken for AD only ! smb.conf: [Global] available= yes client signing= auto server signing= auto server string= MyName Workgroup= DISNEY netbios name= px6-300d-2 realm= DISNEY.LLTEST.TPA-ELD.LOCALDOMAIN password server= * idmap backend= tdb idmap uid= 5000-9999999 idmap gid= 5000-9999999 idmap config DISNEY : backend= rid idmap config DISNEY : range= 10000000-19999999 security= ADS name resolve order= wins host bcast lmhosts client use spnego= yes dns proxy= no winbind use default domain= no winbind nested groups= yes inherit acls= yes winbind enum users= yes winbind enum groups= yes winbind separator= \\ winbind cache time= 300 winbind offline logon= true template shell= /bin/sh map to guest= Bad User host msdfs= yes restrict anonymous= 0 strict allocate= yes encrypt passwords= yes passdb backend= smbpasswd printcap name= lpstat printable= no load printers= yes max smbd processes= 500 getwd cache= yes use sendfile= yes browse directory= /tmp/samba winbind sequence directory= /tmp/samba unix extensions= no veto files= /.AppleDouble/.AppleDB/.bin/.AppleDesktop/Network Trash Folder/Temporary Items/:2eDS_Store/ dos charset= ascii log file= /tmp/samba/log.smbd syslog= 10 log level= 10 max log size= 0 [wgsharetest] path= /mnt/pools/A/A0/wgsharetest/ max connections= 150 directory mode= 0777 create mode= 0777 follow symlinks= yes wide links= no nt acl support= yes dos filemode= yes writeable= no valid users= "wguser1" "wguser2" store dos attributes= yes write list= "wguser1" "wguser2" [adsharetest] path= /mnt/pools/A/A0/adsharetest/ max connections= 150 directory mode= 0777 create mode= 0777 follow symlinks= yes wide links= no nt acl support= yes dos filemode= yes writeable= no valid users= "disney\user_001" "disney\user_002" store dos attributes= yes write list= "disney\user_001" "disney\user_002" This is a serious bug for Enterprises, since any blacklisted employee would gain acces to classified files
Created attachment 9268 [details] Samba's log level 10 file
OK, I took a look at the log. The problem is the DENY ACE entry is being set on the *group* SID DISNEY\user_2, not on the user SID DISNEY\user_2. Group ACE's aren't specific to members, they're cumulative so the deny is being overridden by the allows on the other groups the user is in. Looks like the uid/gid mapping is not right here. Jeremy.
(In reply to comment #2) > OK, I took a look at the log. > > The problem is the DENY ACE entry is being set on the *group* SID > DISNEY\user_2, not on the user SID DISNEY\user_2. Group ACE's aren't specific > to members, they're cumulative so the deny is being overridden by the allows on > the other groups the user is in. > > Looks like the uid/gid mapping is not right here. > > Jeremy. Thanks, Jeremy. I am not sure if I followed. Do you mean the mapping at smb.conf is not right or maybe samba is not correctly handling a correct mapping ? idmap backend= tdb idmap uid= 5000-9999999 idmap gid= 5000-9999999 idmap config DISNEY : backend= rid idmap config DISNEY : range= 10000000-19999999
Ah, I think I finally see the problem here... This is *really* subtle and would only affect DENY ACE entries. Give me a little while to look at a possible patch. Jeremy.
Created attachment 9409 [details] git-am fix for 4.1.next and 4.0.next git-am fix that went into master, cherry-picked for 4.1.next and 4.0.next. Applies cleanly to both. Jeremy
Comment on attachment 9409 [details] git-am fix for 4.1.next and 4.0.next Reporter confirms this fixes the issue.
Re-assigning to Karolin for inclusion in 4.1.next, 4.0.next. Thanks David ! Jeremy.
Pushed to autobuild-v4-1-test and autobuild-v4-0-test.
Pushed to v4-1-test and v4-0-test. Closing out bug report. Thanks!