Version 4.0.0alpha21-GIT-0fefe24 When a file is created in a share, the posix acl which is set on the share is not set correctly by s3fs. A user steve2 is a member of a group called staff. The share is called reports. steve 2 has primaryGroupID 513, Domain Users reports is: drwxrws---+ 2 root staff 4096 May 11 09:03 reports and was created as follows: mkdir reports chmod 0770 reports chgrp staff reports chmod g+s reports setfacl -d -Rm g::rwx reports getfacl reports # file: reports # owner: root # group: staff # flags: -s- user::rwx group::rwx other::--- default:user::rwx default:group::rwx default:other::--- steve2 authenticates via Samba4 and moves to the share. If he creates a file on a Linux client over nfs (or on the same on the server, we have S4 and s3fs on the same Linux box) the file is created: steve2@sam4dc:/data/reports$ touch hola.txt steve2@sam4dc:/data/reports$ ls -l hola.txt -rw-rw---- 1 steve2 staff 0 May 12 08:25 hola.txt Correct according to the acl on reports: -rw-rw---- Note that there is no acl on the file just created. If steve2 now logs into windows and creates a file in the same share, the staff group is not inherited (it becomes and the ACL has been converted to -rwxrwx---+ -rwxrwx---+ 1 steve2 Domain Users 58 May 11 19:07 New Text Document.txt The file created in windows by s3fs is not -rw-rw---- and it has an acl set: getfacl New\ Text\ Document.txt # file: New Text Document.txt # owner: steve2 # group: Domain\040Users user::rwx user:steve2:rwx group::rwx group:Domain\040Users:rwx mask::rwx other::--- Further, if steve2 now goes to his /home directory with no ACL set and creates a file, in Linux it becomes: steve2@sam4dc:~$ touch hola2.txt steve2@sam4dc:~$ ls -l hola2.txt -rw-r--r-- 1 steve2 Domain Users 0 May 12 08:32 hola2.txt In windows if steve creates a file in his home folder, it becomes: -rwxrwxr-x+ 1 steve2 Domain Users 0 May 10 11:31 New Text Document.txt I think the Linux behaviour is correct. We want group rw with files creates -rw-rw steve2:staff as the acl dictates This is always reproducible with and without the nfs server. ### ### ### ### data from the setup ### ### ### ### wbinfo -i steve2 CACTUS\steve2:*:3000008:20513::/home/CACTUS/steve2:/bin/false getent passwd steve2 steve2:*:3000008:20513:steve2:/home2/CACTUS/steve2:/bin/bash getent group staff staff:*:21106:lynn2,steve2 Domain Users in idmap: dn: CN=S-1-5-21-1196638036-2541980263-511278767-513 cn: S-1-5-21-1196638036-2541980263-511278767-513 objectClass: sidMap objectSid: S-1-5-21-1196638036-2541980263-511278767-513 type: ID_TYPE_GID xidNumber: 20513 distinguishedName: CN=S-1-5-21-1196638036-2541980263-511278767-513 steve2 in idmap: dn: CN=S-1-5-21-1196638036-2541980263-511278767-1105 cn: S-1-5-21-1196638036-2541980263-511278767-1105 objectClass: sidMap objectSid: S-1-5-21-1196638036-2541980263-511278767-1105 type: ID_TYPE_BOTH xidNumber: 3000008 distinguishedName: CN=S-1-5-21-1196638036-2541980263-511278767-1105 staff in idmap: dn: CN=S-1-5-21-1196638036-2541980263-511278767-1106 cn: S-1-5-21-1196638036-2541980263-511278767-1106 objectClass: sidMap objectSid: S-1-5-21-1196638036-2541980263-511278767-1106 type: ID_TYPE_BOTH xidNumber: 21106 distinguishedName: CN=S-1-5-21-1196638036-2541980263-511278767-1106 wbinfo --group-info=staff staff:*:21106: # record 1 dn: CN=steve2,CN=Users,DC=polop,DC=site cn: steve2 instanceType: 4 whenCreated: 20120508141303.0Z uSNCreated: 3719 name: steve2 objectGUID: 2e73c14e-976e-431e-830e-863494cc4a1c badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 objectSid: S-1-5-21-1196638036-2541980263-511278767-1105 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: steve2 sAMAccountType: 805306368 userPrincipalName: steve2@polop.site objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=polop,DC=site pwdLastSet: 129809599830000000 userAccountControl: 512 uidNumber: 3000008 unixHomeDirectory: /home2/CACTUS/steve2 loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: person objectClass: organizationalPerson objectClass: user profilePath: \\sam4dc\profiles\steve2 homeDrive: Z: homeDirectory: \\sam4dc\home\steve2 memberOf: CN=staff,CN=Users,DC=polop,DC=site primaryGroupID: 513 gidNumber: 20513 whenChanged: 20120511065427.0Z uSNChanged: 3846 distinguishedName: CN=steve2,CN=Users,DC=polop,DC=site # record 1 dn: CN=staff,CN=Users,DC=polop,DC=site cn: staff instanceType: 4 whenCreated: 20120508143644.0Z uSNCreated: 3725 name: staff objectGUID: 2c910ec0-0508-4f48-90df-544aa47c8d65 objectSid: S-1-5-21-1196638036-2541980263-511278767-1106 sAMAccountName: staff sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=polop,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21106 member: CN=steve2,CN=Users,DC=polop,DC=site member: CN=lynn2,CN=Users,DC=polop,DC=site whenChanged: 20120511165601.0Z uSNChanged: 3855 distinguishedName: CN=staff,CN=Users,DC=polop,DC=site cat /usr/local/samba/etc/smb.conf # Global parameters [global] server role = domain controller workgroup = CACTUS realm = polop.site netbios name = SAM4DC passdb backend = samba4 dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, s3fs [netlogon] path = /usr/local/samba/var/locks/sysvol/polop.site/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sysvol read only = No [home] path = /home2/CACTUS read only = No [profiles] path = /home2/CACTUS/profiles read only = No [data] path = /data read only = No browseable = Yes [reports] path = /data/reports read only = No create mask = 0770
For the group rw acl, it seems to be only the chmod g+s that's missing, not the acl. Otherwise it's fine. The file created should be steve2:staff but under s3fs it is steve2:Domain Users. That's all. The problem about files not being created rw-r-r in steve2's home directory is still present. Please do not take this as a bump or impatience. No rush. Just extra info:)
I will confirm this bug, and add a bit of info here too. By the way I added winbind separator = / in my smb.conf so it looks a bit cleaner ;) I can reproduce this as follows... # touch myfile # id test.user uid=3000018(WEAUBLEAU/test.user) gid=100(users) groups=100(users) # setfacl -m u:3000018:rwx myfile # getfacl myfile # file: myfile # owner: root # group: root user::rw- user:WEAUBLEAU/test.user:rwx group::r-- mask::rwx other::r-- In windows I see that test user has all the ACL's for that file (except special permissions), however the problem I see is when I do the same for a directory (test3 in the following example) # mkdir test3 # setfacl -m u:3000018:rwx test3 # getfacl test3 # file: test3 # owner: root # group: root user::rwx user:WEAUBLEAU/test.user:rwx group::r-x mask::rwx other::r-x But the permissions in windows shows the user test.user with NO ACL's as seen in the following screenshot http://picpaste.com/pics/acls-qFa8jStz.1337310153.png This is a test machine setup with s3fs and a git pull from about 3 hrs ago on abartlets/samba-devel branch. I will also not that when creating a folder on the same share as Administrator in windows, it has the same result, Administrator has no ACL's reported by windows. Once the folder is changed in windows it looks like this to linux. # getfacl test3 # file: test3 # owner: root # group: root user::rwx user:root:rwx group::r-x group:root:r-x group:3000018:rwx mask::rwx other::r-x default:user::rwx default:user:root:rwx default:group::r-x default:group:root:r-x default:group:3000018:rwx default:mask::rwx default:other::r-x Just a bit more info.
(In reply to comment #2) > I will confirm this bug, and add a bit of info here too. By the way I added > winbind separator = / in my smb.conf so it looks a bit cleaner ;) > > I can reproduce this as follows... > # touch myfile > # id test.user > uid=3000018(WEAUBLEAU/test.user) gid=100(users) groups=100(users) > # setfacl -m u:3000018:rwx myfile > # getfacl myfile > # file: myfile > # owner: root > # group: root > user::rw- > user:WEAUBLEAU/test.user:rwx > group::r-- > mask::rwx > other::r-- > > In windows I see that test user has all the ACL's for that file (except special > permissions), however the problem I see is when I do the same for a directory > (test3 in the following example) > > > # mkdir test3 > # setfacl -m u:3000018:rwx test3 > # getfacl test3 > # file: test3 > # owner: root > # group: root > user::rwx > user:WEAUBLEAU/test.user:rwx > group::r-x > mask::rwx > other::r-x > > But the permissions in windows shows the user test.user with NO ACL's as seen > in the following screenshot > http://picpaste.com/pics/acls-qFa8jStz.1337310153.png > You shouldn't trust too much what you see in the ACL interpretation, I've seen this a high number of time but still ACLs are correctly enforced. Can you: 1) check that user test can create files in this test3 dir ? 2) try with a user test2 and see if he can't create file in test3 dir ?
Steve, can you check that it works as expected with NTVFS ? I suspect it will work only if you are member of the group that is set as +s on unix (ie. staff in your example). Can you also check this ?
Yes. Can confirm ntvfs works fine on permissions set on Linux and preserves g+s on shares. However, if we set an acl on windows, the same acl is not then understood back at posix level. Worse: No matter what we set on Linux, the domain Administrator does not see anything set. He has no access to any share unless he sets the total control permissions himself. If he does that, he really messes up the posix permissions back on Linux. Could we forget the ntvfs permissions for the sake of this bug? Focus on simply getting a g+s share set on Linux to be honoured by S3fs for the moment? I feel that if this were in place, the rest would follow easily. SUMMARY What does not work is: 1. the g+s on the underlying files system (ext4 in this case) 2. files are created -rwxrwxr-x+ instead of -rw-r--r-- in the users home directory.
Much better Version 4.0.0alpha22-GIT-633060f When I now create a file, it still appears as -rwxrwxr-x+ but now, no one other than the owner can write to it. Perfect. would it be possible to translate the -rwxrwxr-x+ to rw-r-r Which it really is? The point about s3fs not understanding what chmod g+s means remains. I can however work around that by creating the share as group staff and giving only staff full control in the windows security tab. Administrator does not by default have any access to any files unless he specifically gives it to himself. In windows, the Administrator seems to have access to everything, by default. Would it be possible to set ACL's on an underlying ext4 acl,user-xattr file system and that this be understood by windows without having to touch the security tab on the share? Thank you. This is almost workable.
Ok, this bug is horribly confusing. What I need is a very simple explanation of what is expected vs. what the smbd server is creating on the share. Look at this bug report as an example of what I need: https://bugzilla.samba.org/show_bug.cgi?id=7812 Or this one: https://bugzilla.samba.org/show_bug.cgi?id=6961 I really need a clear problem statement before I can make progress. Jeremy.
(In reply to comment #7) > Ok, this bug is horribly confusing. What I need is a very simple explanation of > what is expected vs. what the smbd server is creating on the share. > > Look at this bug report as an example of what I need: > > https://bugzilla.samba.org/show_bug.cgi?id=7812 > > Or this one: > > https://bugzilla.samba.org/show_bug.cgi?id=6961 > > I really need a clear problem statement before I can make progress. > > Jeremy. May things have been fixed recently with the latest git releases but these two remain: 1. Creating a file in a g+s share, s3fs creates the file with group ownership of the user who created the file, not the group owner of directory of the share, as it should do with g+s on the directory. 2.Creating a file in a users home folder under Linux correctly produces: -rw-r--r-- 1 steve2 Domain Users 0 May 12 08:32 New Text Document.txt In windows it becomes: -rwxrwxr-x+ 1 steve2 Domain Users 0 May 10 11:31 New Text Document.txt but does indeed behave as -rw-r-r-- Thanks
Ok, case (1) is clearly separate and I can investigate based on that. Your second case needs more elaboration. What are the permissions set on the users home directory ? I need to know both the POSIX ACL or directory permissions (if there is no POSIX ACL) and also the Windows permissions set on the home directory (if there are any). Thanks, Jeremy.
(In reply to comment #9) > Ok, case (1) is clearly separate and I can investigate based on that. > > Your second case needs more elaboration. What are the permissions set on the > users home directory ? I need to know both the POSIX ACL or directory > permissions (if there is no POSIX ACL) and also the Windows permissions set on > the home directory (if there are any). > > Thanks, > > Jeremy. No posix acl has been set on the directory other than that by simply creating it using mkdir: drwxr-xr-x 27 steve2 Domain Users 4096 Jun 19 17:21 steve2 # file: steve2 # owner: steve2 # group: Domain\040Users user::rwx group::r-x other::r-x Nothing has been altered under windows. The security tab on the folder steve2 shows a blank. Nothing is checked. Clicking the 'Advanced' button on the security tab and then the 'Edit' button shows steve2 having full control (everything is ticked) to 'This folder only' As I say, when a file is created in the home folder from windows, the permissions are working as if they were rw r r but show up as -rwxrwxr-x+. Not a problem. Thanks Steve
Hi Jeremy, regarding case (1): > 1. Creating a file in a g+s share, s3fs creates the file with group ownership > of the user who created the file, not the group owner of directory of the > share, as it should do with g+s on the directory. I guess Bug 9054 shows a similar behaviour in 3.6.6, maybe it offers additional information.
Does this problem still happen with the released Samba 4.0.0?
(In reply to comment #12) > Does this problem still happen with the released Samba 4.0.0? Yes. And with 4.0.8: g+s is still not working over cifs. Thanks
(In reply to comment #13) > (In reply to comment #12) > > Does this problem still happen with the released Samba 4.0.0? > > Yes. And with 4.0.8: g+s is still not working over cifs. > Thanks The acl_xattr vfs module triggers the g+s overwrite...
Created attachment 10714 [details] Enforce gid when container has sgid bit set Inspired by patches found in relative bug #9054, but changes are only in the acl_xattr module code. Any suggestion about the approch or some side effects ?
Additional information : with the previous patch the NT ACL are properly inherited only with the setting acl_xattr:ignore system acls to yes. Without it, the acl are displayed as non-inherited and there's two full-control acl added for the unix owner (uid+gid).
Created attachment 10716 [details] Enforce gid when container has sgid bit set - V2 My previous patch had issues, please ignore it and accept my apologies for my multiple posts. Here is another one, quite simple, that simply inherit container's unix gid if the container is sgid. With the setting "acl_xattr:ignore system acls" to yes, everything seems to be fonctionnal and acl are properly inherited and displayed. With the setting "acl_xattr:ignore system acls" to no, everything seems to be fonctionnal, but ACL aren't displayed as inherited when they should be, and some ACL are added : - Creator Owner - Creator Group - Domain user correspondind to object's UID - Domain group correspondind to object's GID
*** This bug has been marked as a duplicate of bug 9054 ***