Question about vfs_acl_common not setting filesystem permissions anymore

Thomas Schulz schulz at adi.com
Thu Aug 25 15:38:53 UTC 2016


If you are going to redo the ACL stuff, please look at Bug 10647.

> On 2016-08-24 at 22:03 +0200, Ralph B=F6hme wrote:
>> On Wed, Aug 24, 2016 at 11:51:14AM -0700, Jeremy Allison wrote:
>>> On Wed, Aug 24, 2016 at 12:53:15PM +0200, Ralph B=F6hme wrote:
>>>> Hi Uri,
>>>>=20
>>>> I wonder whether this change
>>>>=20
>>>>   765e5f1 vfs_acl_common: avoid setting POSIX ACLs if "ignore system =
> acls" is set
>>>>=20
>>>> is correct.
>>>>=20
>>>> The kernel will still perform permissions checks, so even if the
>>>> ACL-blob permission checks in se_file_access_check() grants access,
>>>> the kernel checks can return EACCESS as the smbd session process runs
>>>> with euid of the authenticated user.
>>>>=20
>>>> How is this supposed to work? Maybe I'm missing something.
>>>>=20
>>>> Simple example:
>>>>=20
>>>> [share]
>>>>     path =3D /data/share
>>>>     vfs objects =3D acl_xattr
>>>>     acl_xattr:ignore system acls =3D yes
>>>>=20
>>>> $ ./bin/smbcacls -Uslow%x //localhost/share "dir"
>>>> REVISION:1
>>>> CONTROL:SR|DP
>>>> OWNER:SLOWSERVER\slow
>>>> GROUP:SLOWSERVER\None
>>>> ACL:SLOWSERVER\slow:ALLOWED/OI|CI/FULL
>>>> ACL:SLOWSERVER\fast:ALLOWED/OI|CI/FULL
>>>>=20
>>>> $ ls -ld /data/share/dir/
>>>> drwxr-xr-x. 3 slow slow 4096 Aug 24 11:42 /data/share/dir/
>>>>=20
>>>> $ ./bin/smbclient -Ufast%x //localhost/share -c "put README dir/READM=
> E"
>>>> Domain=3D[SLOW] OS=3D[Windows 6.1] Server=3D[Samba 4.6.0pre1-DEVELOPE=
> RBUILD]
>>>> NT_STATUS_ACCESS_DENIED opening remote file \dir/README
>>>>=20
>>>> This fails even though the NT ACL grants access because the filesytem
>>>> permissions don't. Change filesystem permissions at it works:
>>>>=20
>>>> $ chmod 0777 /data/share/inherit_dir/
>>>> $ ./bin/smbclient -Ufast%x //localhost/share -c "put README dir/READM=
> E"
>>>> Domain=3D[SLOW] OS=3D[Windows 6.1] Server=3D[Samba 4.6.0pre1-DEVELOPE=
> RBUILD]
>>>> putting file README as \inherit_dir/README (8650.5 kb/s) (average 865=
> 1.4 kb/s)
>>>>=20
>>>> The POSIX permissions for directories created by SMB clients are
>>>> governed by "directory mask" which is 0755 by default. Maybe forcing
>>>> "directory mask =3D 0777" and "create mask =3D 0777" in
>>>> connect_acl_xattr() and connect_acl_tdb() would work, not
>>>> sure. Otherwise I think we may have to revert this change.
>>>=20
>>> IMHO setting "acl_xattr:ignore system acls =3D yes" essentially
>>> means that the underlying file system isn't really POSIX,
>>> or isn't prohibiting access in any way (after all, why set
>>> "ignore system acls =3D yes" if you don't want to ignore
>>> system acls ? :-).
>>=20
>> I take this slightly differently: "acl_xattr:ignore system acls =3D yes"
>> is the most sensible setting if there's no need for cross-protocol
>> support. Most of the times this will be using a POSIX filesystem.
> 
> I see it exactly the same way.
> 
>>> It really is an unusual use-case mainly for OEMs who
>>> should be setting this up correctly for their users.
>>=20
>> Hm, I guess this would be the usual setup I'd do on a typical
>> fileserver without the need for cross protocol support. :)
> 
> Same here.
> 
>>> So I don't think reverting is the right thing to do here.
>>=20
>> Agreed.
>>=20
>>> I'm OK with changing "directory mask" and "create mask" to
>>> make this work on an underlying POSIX system, and maybe
>>> we need to update the man page to make it explicit that
>>> the admin has to ensure this really is running on a system
>>> that ignores any system acls.
>>=20
>> Ok, I'll prepare patches. Thanks for chiming in!
> 
> I'm curious what they'll look like.
> 
> Michael
> 
> --yrj/dFKFPuw6o+aM
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iEYEARECAAYFAle+CboACgkQyU9JOBhPkDRa2wCfeC/vMfIPb90bE59VB97Jhn+u
> +h0AoKNIGo5jPo/Cp9hTwxzlUbUGGl/Y
> =AQiI
> -----END PGP SIGNATURE-----
> 
> --yrj/dFKFPuw6o+aM--
> 

Tom Schulz
Applied Dynamics Intl.
schulz at adi.com



More information about the samba-technical mailing list