samba - Aug 2016 - Issue with acl_xattr:ignore system acls in 4.5rc2

On 08/18/2016 08:28 AM, Ralph Böhme wrote:
> Hi Eric,
> 
> On Wed, Aug 17, 2016 at 05:56:51PM -0600, Eric Eastman via samba wrote:
>> I was testing Samba 4.5rc2 with an existing smb.conf file that I have
been
>> using since Samba 4.1.x and found that I cannot access data in the
share on
>> Windows 2012 (my AD server), a Windows 2008 client or on a Ubuntu 16.04
>> client.  I built a new version of Samba 4.4.5 using the same procedure
as I
>> did for building 4.5rc2 and the 4.4.5 Samba version worked with my
smb.conf
>> file.  I then created a very basic smb.conf file and slowly built it
up,
>> and by doing testing between 4.4.5 and 4.5rc2, I finally found the line
>> that caused the problem. Here is my cut down smb.conf file:
>>
>> [global]
>> security = ads
>> realm = ERIC.LOCAL
>> workgroup = ERIC
>> netbios name = C1-GW03-T5
>> idmap uid = 500-10000000
>> idmap gid = 500-10000000
>> winbind use default domain = Yes
>> winbind nested groups = Yes
>> map acl inherit = yes
>> vfs objects = acl_xattr streams_xattr
>> acl_xattr:ignore system acls = yes
>> load printers = no
>> printcap name = /dev/null
>>
>> [zzz]
>> path = /zzz
>> writeable = yes
>> browseable = yes
>>
>>
>> The line causing the problem with 4.5rc2 is:
>>   acl_xattr:ignore system acls = yes
> 
> this change was introduced in
> <https://bugzilla.samba.org/show_bug.cgi?id=12028>
> 
> Before explaining the gory details, one question: why are you setting
> this option?
> 
> With the patches from the bugreport the behaviour of vfs_acl_xattr
> changed when "acl_xattr:ignore system acls" is set to yes for the
case
> a file or directory lacks the NT ACL xattr (eg when creating files and
> directories on the server).
> 
> Before the change, we would query the system POSIX permissions and map
> them to a NT ACL.
> 
> After the change we sythesize a default NT ACL with just
> 
>   ACL:$uid:ALLOWED/0x0/$mapped_mode
>   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> 
> As this severly impacts existing setups, we have three options to
> address this:
> 
> 1. Revert it,
> 2. Document it, or
> 3. Do it differently
> 
> 1. Revert it
> 
> Brings back the original problem: not behaving as a Windows server and
> in certain situations unexpectedly exposing system POSIX permissions
> as described in the above bug.
> 
> 2. Document it
> 
> One could argue that this works as designed, so just add a big note to
> the release notes so people are aware of this change. As everybody
> reads release notes, there'll be no surprise. :)
> 
> When acl_xattr:ignore system acls is set to yes, we now completely
> ignore the system POSIX permissions. Since bug 11806 we already ignore
> the the system POSIX permissions when setting an NT ACL, we now ignore
> them as well when querying them. So this can be seen as improvement
> because previously our behaviour was inconsistent.
> 
> In some sense "acl_xattr:ignore system acls = yes" works like a
> fictional option "acl_xattr:ignore system permissions = yes".
> 
> Any filesytem object without NT ACL xattr will get default permissions
> matching Windows:
> 
>   ACL:$uid:ALLOWED/0x0/$mapped_mode
>   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> 
> This affects directories created on the server, like in Eric'c case,
> or when an SMB client creates a file or directory where the parent
> directory has no inheritable ACEs, as described in bug 12028.
> 
> 3. Do it differently
> 
> Implement the fictional option from 2 "acl_xattr:ignore system
> permissions" and only ignore system POSIX permissions when querying
> permissions if this is set. Sing: one more option before you go, to
> the valley below.
> 
> *scratching head* Thoughts?
> 
> Cheerio!
> -slow
> 
Ralph,

I think the current behavior is correct (also tested it against Windows
for comparison).

However, if it breaks things for users, we need a way out for them, and
the only way out that's guaranteed to work in all cases is a
compatibility switch - generate the "old" DACL as default, wrong or
surprising as it may be, to maintain backward compatibility. So that's
an additional "acl_xattr:legacy default acl = yes" param IMHO.

Thanks,
Uri.

On 2016-08-18 at 12:21 +0300, Uri Simchoni via samba
wrote:
> On 08/18/2016 08:28 AM, Ralph Böhme wrote:
> > Hi Eric,
> > 
> > On Wed, Aug 17, 2016 at 05:56:51PM -0600, Eric Eastman via samba
wrote:
> >> I was testing Samba 4.5rc2 with an existing smb.conf file that I
have been
> >> using since Samba 4.1.x and found that I cannot access data in the
share on
> >> Windows 2012 (my AD server), a Windows 2008 client or on a Ubuntu
16.04
> >> client.  I built a new version of Samba 4.4.5 using the same
procedure as I
> >> did for building 4.5rc2 and the 4.4.5 Samba version worked with my
smb.conf
> >> file.  I then created a very basic smb.conf file and slowly built
it up,
> >> and by doing testing between 4.4.5 and 4.5rc2, I finally found the
line
> >> that caused the problem. Here is my cut down smb.conf file:
> >>
> >> [global]
> >> security = ads
> >> realm = ERIC.LOCAL
> >> workgroup = ERIC
> >> netbios name = C1-GW03-T5
> >> idmap uid = 500-10000000
> >> idmap gid = 500-10000000
> >> winbind use default domain = Yes
> >> winbind nested groups = Yes
> >> map acl inherit = yes
> >> vfs objects = acl_xattr streams_xattr
> >> acl_xattr:ignore system acls = yes
> >> load printers = no
> >> printcap name = /dev/null
> >>
> >> [zzz]
> >> path = /zzz
> >> writeable = yes
> >> browseable = yes
> >>
> >>
> >> The line causing the problem with 4.5rc2 is:
> >>   acl_xattr:ignore system acls = yes
> > 
> > this change was introduced in
> > <https://bugzilla.samba.org/show_bug.cgi?id=12028>
> > 
> > Before explaining the gory details, one question: why are you setting
> > this option?
> > 
> > With the patches from the bugreport the behaviour of vfs_acl_xattr
> > changed when "acl_xattr:ignore system acls" is set to yes
for the case
> > a file or directory lacks the NT ACL xattr (eg when creating files and
> > directories on the server).
> > 
> > Before the change, we would query the system POSIX permissions and map
> > them to a NT ACL.
> > 
> > After the change we sythesize a default NT ACL with just
> > 
> >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > 
> > As this severly impacts existing setups, we have three options to
> > address this:
> > 
> > 1. Revert it,
> > 2. Document it, or
> > 3. Do it differently
> > 
> > 1. Revert it
> > 
> > Brings back the original problem: not behaving as a Windows server and
> > in certain situations unexpectedly exposing system POSIX permissions
> > as described in the above bug.
> > 
> > 2. Document it
> > 
> > One could argue that this works as designed, so just add a big note to
> > the release notes so people are aware of this change. As everybody
> > reads release notes, there'll be no surprise. :)
> > 
> > When acl_xattr:ignore system acls is set to yes, we now completely
> > ignore the system POSIX permissions. Since bug 11806 we already ignore
> > the the system POSIX permissions when setting an NT ACL, we now ignore
> > them as well when querying them. So this can be seen as improvement
> > because previously our behaviour was inconsistent.
> > 
> > In some sense "acl_xattr:ignore system acls = yes" works
like a
> > fictional option "acl_xattr:ignore system permissions =
yes".
> > 
> > Any filesytem object without NT ACL xattr will get default permissions
> > matching Windows:
> > 
> >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > 
> > This affects directories created on the server, like in Eric'c
case,
> > or when an SMB client creates a file or directory where the parent
> > directory has no inheritable ACEs, as described in bug 12028.
> > 
> > 3. Do it differently
> > 
> > Implement the fictional option from 2 "acl_xattr:ignore system
> > permissions" and only ignore system POSIX permissions when
querying
> > permissions if this is set. Sing: one more option before you go, to
> > the valley below.
> > 
> > *scratching head* Thoughts?
> > 
> > Cheerio!
> > -slow
> > 
> Ralph,
> 
> I think the current behavior is correct (also tested it against Windows
> for comparison).
> 
> However, if it breaks things for users, we need a way out for them, and
> the only way out that's guaranteed to work in all cases is a
> compatibility switch - generate the "old" DACL as default, wrong
or
> surprising as it may be, to maintain backward compatibility. So that's
> an additional "acl_xattr:legacy default acl = yes" param IMHO.
From reading the original post, I get the impression
that the problem is associated to the share root directory.
There is of cours a chicken-and-egg problem here.

And my wild guess is that this could be fixed with setting
a proper share acl. (use the sharesec command).
Maybe we must also/alternatively put a different xattr-acl for
the share root.

Otherwise I fully agree that the new behaviour seems to be
the correct one to me.

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160818/6e7fd7df/signature.sig>

On Thu, Aug 18, 2016 at 12:21:37PM +0300, Uri Simchoni
wrote:
> On 08/18/2016 08:28 AM, Ralph Böhme wrote:
> > Hi Eric,
> > 
> > On Wed, Aug 17, 2016 at 05:56:51PM -0600, Eric Eastman via samba
wrote:
> >> I was testing Samba 4.5rc2 with an existing smb.conf file that I
have been
> >> using since Samba 4.1.x and found that I cannot access data in the
share on
> >> Windows 2012 (my AD server), a Windows 2008 client or on a Ubuntu
16.04
> >> client.  I built a new version of Samba 4.4.5 using the same
procedure as I
> >> did for building 4.5rc2 and the 4.4.5 Samba version worked with my
smb.conf
> >> file.  I then created a very basic smb.conf file and slowly built
it up,
> >> and by doing testing between 4.4.5 and 4.5rc2, I finally found the
line
> >> that caused the problem. Here is my cut down smb.conf file:
> >>
> >> [global]
> >> security = ads
> >> realm = ERIC.LOCAL
> >> workgroup = ERIC
> >> netbios name = C1-GW03-T5
> >> idmap uid = 500-10000000
> >> idmap gid = 500-10000000
> >> winbind use default domain = Yes
> >> winbind nested groups = Yes
> >> map acl inherit = yes
> >> vfs objects = acl_xattr streams_xattr
> >> acl_xattr:ignore system acls = yes
> >> load printers = no
> >> printcap name = /dev/null
> >>
> >> [zzz]
> >> path = /zzz
> >> writeable = yes
> >> browseable = yes
> >>
> >>
> >> The line causing the problem with 4.5rc2 is:
> >>   acl_xattr:ignore system acls = yes
> > 
> > this change was introduced in
> > <https://bugzilla.samba.org/show_bug.cgi?id=12028>
> > 
> > Before explaining the gory details, one question: why are you setting
> > this option?
> > 
> > With the patches from the bugreport the behaviour of vfs_acl_xattr
> > changed when "acl_xattr:ignore system acls" is set to yes
for the case
> > a file or directory lacks the NT ACL xattr (eg when creating files and
> > directories on the server).
> > 
> > Before the change, we would query the system POSIX permissions and map
> > them to a NT ACL.
> > 
> > After the change we sythesize a default NT ACL with just
> > 
> >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > 
> > As this severly impacts existing setups, we have three options to
> > address this:
> > 
> > 1. Revert it,
> > 2. Document it, or
> > 3. Do it differently
> > 
> > 1. Revert it
> > 
> > Brings back the original problem: not behaving as a Windows server and
> > in certain situations unexpectedly exposing system POSIX permissions
> > as described in the above bug.
> > 
> > 2. Document it
> > 
> > One could argue that this works as designed, so just add a big note to
> > the release notes so people are aware of this change. As everybody
> > reads release notes, there'll be no surprise. :)
> > 
> > When acl_xattr:ignore system acls is set to yes, we now completely
> > ignore the system POSIX permissions. Since bug 11806 we already ignore
> > the the system POSIX permissions when setting an NT ACL, we now ignore
> > them as well when querying them. So this can be seen as improvement
> > because previously our behaviour was inconsistent.
> > 
> > In some sense "acl_xattr:ignore system acls = yes" works
like a
> > fictional option "acl_xattr:ignore system permissions =
yes".
> > 
> > Any filesytem object without NT ACL xattr will get default permissions
> > matching Windows:
> > 
> >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > 
> > This affects directories created on the server, like in Eric'c
case,
> > or when an SMB client creates a file or directory where the parent
> > directory has no inheritable ACEs, as described in bug 12028.
> > 
> > 3. Do it differently
> > 
> > Implement the fictional option from 2 "acl_xattr:ignore system
> > permissions" and only ignore system POSIX permissions when
querying
> > permissions if this is set. Sing: one more option before you go, to
> > the valley below.
> > 
> > *scratching head* Thoughts?
> 
> I think the current behavior is correct (also tested it against Windows
> for comparison).
thanks for confirming.
> However, if it breaks things for users, we need a way out for them, and
> the only way out that's guaranteed to work in all cases is a
> compatibility switch - generate the "old" DACL as default, wrong
or
> surprising as it may be, to maintain backward compatibility. So that's
> an additional "acl_xattr:legacy default acl = yes" param IMHO.
well, if we conclude we need a new option that

a) preserves existing behaviour, and

b) allows enabling full Windows compatibility by completely ignoring
   system POSIX permissions,

then my suggestion would be

o restore the previous behaviour of "acl_xattr:ignore system acls  
yes", in order not to break exisiting setups, and

o add a new option that would tell us to completely ignore system
  POSIX permissions when querying and setting, defaulting to off:

  acl_xattr:ignore system permissions = yes | no (default: no)

  "acl_xattr:ignore system permissions = yes" implicitly sets
  "acl_xattr:ignore system acls = yes"

The name "ignore system permissions" also better reflects the fact
that this option is not only about ACLs, but about system permissions
including POSIX mode.

We should then mark "acl_xattr:ignore system acls" as legacy and
explain the broken behaviour (system permisions ignored when setting,
but sometimes (when the filesystem object lacks an NT ACL xattr) still
used when querying).

*still scratching head* :) Thoughts?

Cheerio!
-slow

Hi Michael,

On Thu, Aug 18, 2016 at 11:42:12AM +0200, Michael Adam
wrote:
> From reading the original post, I get the impression
> that the problem is associated to the share root directory.
nope. It will happen with just any directory or file created from a
non SMB client, eg mkdir|touch (or NFS, ...) on the server.

It is also associated with files or directories created from Windows
client where the parent directory for some reason lacks inheritable
ACEs (because eg the admin relied on POSIX mode for some basic
permissions).
> There is of cours a chicken-and-egg problem here.
> 
> And my wild guess is that this could be fixed with setting
> a proper share acl. (use the sharesec command).
> Maybe we must also/alternatively put a different xattr-acl for
> the share root.
Just adding inheritable (NT ACL xattr) ACEs to the share root
directory indeed fixes the problem for SMB clients, but not for stuff
created on the server.

Cheerio!
-slow

On 2016-08-18 at 12:31 +0200, Ralph Böhme via samba
wrote:
> On Thu, Aug 18, 2016 at 12:21:37PM +0300, Uri Simchoni wrote:
> > On 08/18/2016 08:28 AM, Ralph Böhme wrote:
> > > Hi Eric,
> > > 
> > > On Wed, Aug 17, 2016 at 05:56:51PM -0600, Eric Eastman via samba
wrote:
> > >> I was testing Samba 4.5rc2 with an existing smb.conf file
that I have been
> > >> using since Samba 4.1.x and found that I cannot access data
in the share on
> > >> Windows 2012 (my AD server), a Windows 2008 client or on a
Ubuntu 16.04
> > >> client.  I built a new version of Samba 4.4.5 using the same
procedure as I
> > >> did for building 4.5rc2 and the 4.4.5 Samba version worked
with my smb.conf
> > >> file.  I then created a very basic smb.conf file and slowly
built it up,
> > >> and by doing testing between 4.4.5 and 4.5rc2, I finally
found the line
> > >> that caused the problem. Here is my cut down smb.conf file:
> > >>
> > >> [global]
> > >> security = ads
> > >> realm = ERIC.LOCAL
> > >> workgroup = ERIC
> > >> netbios name = C1-GW03-T5
> > >> idmap uid = 500-10000000
> > >> idmap gid = 500-10000000
> > >> winbind use default domain = Yes
> > >> winbind nested groups = Yes
> > >> map acl inherit = yes
> > >> vfs objects = acl_xattr streams_xattr
> > >> acl_xattr:ignore system acls = yes
> > >> load printers = no
> > >> printcap name = /dev/null
> > >>
> > >> [zzz]
> > >> path = /zzz
> > >> writeable = yes
> > >> browseable = yes
> > >>
> > >>
> > >> The line causing the problem with 4.5rc2 is:
> > >>   acl_xattr:ignore system acls = yes
> > > 
> > > this change was introduced in
> > > <https://bugzilla.samba.org/show_bug.cgi?id=12028>
> > > 
> > > Before explaining the gory details, one question: why are you
setting
> > > this option?
> > > 
> > > With the patches from the bugreport the behaviour of
vfs_acl_xattr
> > > changed when "acl_xattr:ignore system acls" is set to
yes for the case
> > > a file or directory lacks the NT ACL xattr (eg when creating
files and
> > > directories on the server).
> > > 
> > > Before the change, we would query the system POSIX permissions
and map
> > > them to a NT ACL.
> > > 
> > > After the change we sythesize a default NT ACL with just
> > > 
> > >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> > >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > > 
> > > As this severly impacts existing setups, we have three options to
> > > address this:
> > > 
> > > 1. Revert it,
> > > 2. Document it, or
> > > 3. Do it differently
> > > 
> > > 1. Revert it
> > > 
> > > Brings back the original problem: not behaving as a Windows
server and
> > > in certain situations unexpectedly exposing system POSIX
permissions
> > > as described in the above bug.
> > > 
> > > 2. Document it
> > > 
> > > One could argue that this works as designed, so just add a big
note to
> > > the release notes so people are aware of this change. As
everybody
> > > reads release notes, there'll be no surprise. :)
> > > 
> > > When acl_xattr:ignore system acls is set to yes, we now
completely
> > > ignore the system POSIX permissions. Since bug 11806 we already
ignore
> > > the the system POSIX permissions when setting an NT ACL, we now
ignore
> > > them as well when querying them. So this can be seen as
improvement
> > > because previously our behaviour was inconsistent.
> > > 
> > > In some sense "acl_xattr:ignore system acls = yes"
works like a
> > > fictional option "acl_xattr:ignore system permissions =
yes".
> > > 
> > > Any filesytem object without NT ACL xattr will get default
permissions
> > > matching Windows:
> > > 
> > >   ACL:$uid:ALLOWED/0x0/$mapped_mode
> > >   ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL
> > > 
> > > This affects directories created on the server, like in
Eric'c case,
> > > or when an SMB client creates a file or directory where the
parent
> > > directory has no inheritable ACEs, as described in bug 12028.
> > > 
> > > 3. Do it differently
> > > 
> > > Implement the fictional option from 2 "acl_xattr:ignore
system
> > > permissions" and only ignore system POSIX permissions when
querying
> > > permissions if this is set. Sing: one more option before you go,
to
> > > the valley below.
> > > 
> > > *scratching head* Thoughts?
> > 
> > I think the current behavior is correct (also tested it against
Windows
> > for comparison).
> 
> thanks for confirming.
> 
> > However, if it breaks things for users, we need a way out for them,
and
> > the only way out that's guaranteed to work in all cases is a
> > compatibility switch - generate the "old" DACL as default,
wrong or
> > surprising as it may be, to maintain backward compatibility. So
that's
> > an additional "acl_xattr:legacy default acl = yes" param
IMHO.
> 
> well, if we conclude we need a new option that
> 
> a) preserves existing behaviour, and
> 
> b) allows enabling full Windows compatibility by completely ignoring
>    system POSIX permissions,
> 
> then my suggestion would be
> 
> o restore the previous behaviour of "acl_xattr:ignore system acls >
yes", in order not to break exisiting setups, and
> 
> o add a new option that would tell us to completely ignore system
>   POSIX permissions when querying and setting, defaulting to off:
> 
>   acl_xattr:ignore system permissions = yes | no (default: no)
> 
>   "acl_xattr:ignore system permissions = yes" implicitly sets
>   "acl_xattr:ignore system acls = yes"
> 
> The name "ignore system permissions" also better reflects the
fact
> that this option is not only about ACLs, but about system permissions
> including POSIX mode.
> 
> We should then mark "acl_xattr:ignore system acls" as legacy and
> explain the broken behaviour (system permisions ignored when setting,
> but sometimes (when the filesystem object lacks an NT ACL xattr) still
> used when querying).
> 
> *still scratching head* :) Thoughts?
That sounds reasonable to me.
It's essentially the strict and non-strict modes
that I mentioned, just better.

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160818/1149f629/signature.sig>