Bug 8938 - Samba4: s3fs does not set ACL's correctly
Samba4: s3fs does not set ACL's correctly
Status: RESOLVED DUPLICATE of bug 9054
Product: Samba 4.0
Classification: Unclassified
Component: File services
unspecified
All All
: P5 normal
: ---
Assigned To: Jeremy Allison
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-12 06:54 UTC by steve (retry timeout exceeded; no DNS MX or A record)
Modified: 2016-12-05 15:20 UTC (History)
7 users (show)

See Also:


Attachments
Enforce gid when container has sgid bit set (3.78 KB, patch)
2015-02-10 17:21 UTC, Boris Lechner
no flags Details
Enforce gid when container has sgid bit set - V2 (2.71 KB, patch)
2015-02-12 11:13 UTC, Boris Lechner
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description steve (retry timeout exceeded; no DNS MX or A record) 2012-05-12 06:54:16 UTC
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
Comment 1 steve (retry timeout exceeded; no DNS MX or A record) 2012-05-17 07:39:47 UTC
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:)
Comment 2 Ricky 2012-05-18 03:43:43 UTC
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.
Comment 3 Matthieu Patou 2012-05-24 16:47:51 UTC
(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 ?
Comment 4 Matthieu Patou 2012-05-24 16:50:04 UTC
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 ?
Comment 5 steve (retry timeout exceeded; no DNS MX or A record) 2012-05-24 17:29:31 UTC
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.
Comment 6 steve (retry timeout exceeded; no DNS MX or A record) 2012-05-31 07:44:09 UTC
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.
Comment 7 Jeremy Allison 2012-06-18 23:11:19 UTC
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.
Comment 8 steve (retry timeout exceeded; no DNS MX or A record) 2012-06-19 08:16:20 UTC
(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
Comment 9 Jeremy Allison 2012-06-19 17:37:07 UTC
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.
Comment 10 steve (retry timeout exceeded; no DNS MX or A record) 2012-06-19 18:13:29 UTC
(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
Comment 11 Arvid Requate 2012-08-16 12:46:06 UTC
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.
Comment 12 Andrew Bartlett 2012-12-31 03:46:58 UTC
Does this problem still happen with the released Samba 4.0.0?
Comment 13 steve (retry timeout exceeded; no DNS MX or A record) 2013-08-06 16:52:16 UTC
(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
Comment 14 Stefan Metzmacher 2014-03-21 20:30:35 UTC
(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...
Comment 15 Boris Lechner 2015-02-10 17:21:33 UTC
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 ?
Comment 16 Boris Lechner 2015-02-11 08:05:26 UTC
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).
Comment 17 Boris Lechner 2015-02-12 11:13:12 UTC
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
Comment 18 Björn Jacke 2016-12-05 15:20:30 UTC

*** This bug has been marked as a duplicate of bug 9054 ***