Bug 9033 - Winbind not reading extended file permissions correctly
Summary: Winbind not reading extended file permissions correctly
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.5.10
Hardware: x64 Linux
: P5 major
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-09 14:14 UTC by csc4096
Modified: 2018-03-27 20:52 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 csc4096 2012-07-09 14:14:12 UTC
Samba: 3.5.10-116.el6-2 on Centos 6.2
Windows: Windows 7 SP1 

Steps to reproduce: (on Linux)
1. mkdir test

2. getfacl test
# file: test
# owner: user1
# group: group1
user::rwx
group::r-x
other::r-x

3. setfacl -m d:g::rwx test

4. getfacl test
# file: test
# owner: user1
# group: group1
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

5. chown user2 test

6. getfacl test
# file: test
# owner: user2
# group: group1
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

[At this stage the directory is still viewable in both Linux and Explorer as user1]

7. chmod 770 test

8 getfacl test
# file: test
# owner: user2
# group: group1
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::r-x

Result: directory is still viewable under linux but Windows reports "You do not have permission" when attempting to access by user1

Fix:
If winbind and samba on Linux are restarted then Explorer correctly allows access by user1

------
smb.conf (edited)
[global]
        workgroup = XXX
        max log size = 100
        preserve case = yes
        short preserve case = no
        security = ads
        realm = XXX.YYY.ZZZ
        encrypt passwords = yes
	load printers = no
        local master = no
        client use spnego = yes
        log level = 100
	use client driver = no
	map to guest = Bad User
	guest account = cifsauth
        domain master = no
        domain logons = no
        machine password timeout = 0
        obey pam restrictions = yes
        kerberos method = dedicated keytab
        dedicated keytab file = /etc/opt/quest/vas/host.keytab
        winbind nested groups = no
      ldap admin dn = CN=VasIdmapAdmin
idmap backend = ldap:ldap://localhost
idmap uid = 10000-2147483647
idmap gid = 10000-2147483647
idmap cache time = 300
	nt acl support = yes
	hide dot files = yes
	ldap ssl = off
; Local Share Configurations
[shareddirectory]
	writeable = yes
	guest ok = no
        path = /home/shareddirectory
Comment 1 Björn Jacke 2018-03-27 20:52:00 UTC
the smb user1 has probably different effective group memberships which can be a result of wrong or not clean id mappings or other configuration glitches.