samba - Jun 2019 - Problems with inconsistent ACL inheritance and permissions after Samba upgrade

On 11/06/19 16:44, Sebastian Arcus via samba wrote:
> 
> On 11/06/19 14:54, Sebastian Arcus via samba wrote:
>>
>> On 11/06/19 13:29, Rowland penny via samba wrote:
>>> On 11/06/2019 13:13, Sebastian Arcus via samba wrote:
>>>>
>>>> On 11/06/19 11:49, Rowland penny via samba wrote:
>>>>> On 11/06/2019 11:38, Sebastian Arcus via samba wrote:
>>>>>>
>>>>>> On 11/06/19 11:07, Rowland penny via samba wrote:
>>>>>>> On 11/06/2019 10:34, Sebastian Arcus via samba
wrote:
>>>>>>>> I've just upgraded a Samba AD server to
4.10.2 a few weeks ago
>>>>>>>> from 4.x (I'm afraid I'm not sure the
exact earlier version) -
>>>>>>>> and since then I just haven't managed to
pin down the file
>>>>>>>> permissions and inheritance on the shares as
it's been
>>>>>>>> constantly causing issues. This server is both
a file server and
>>>>>>>> a AD DC.
>>>>>>>>
>>>>>>>> The current problem I am facing is the
permissions of the lock
>>>>>>>> file generated by Microsoft Access (.ldb). The
Access database
>>>>>>>> is on the server share. When one Windows client
opens it, the
>>>>>>>> .ldb file is created with group write
permission (-rw-rw----).
>>>>>>>> But when it is opened from another Windows
machine, the .ldb
>>>>>>>> file is created with group read-only
permissions (-rw-r-----) -
>>>>>>>> which locks other users out. There seems to be
a mask applied,
>>>>>>>> but I have no idea where is it coming from.
Both client machines
>>>>>>>> are Windows 7 - I just can't figure out the
reason. It used to
>>>>>>>> work fine before the Samba upgrade. The wrong
acl's for the .ldb
>>>>>>>> file look like this:
>>>>>>>>
>>>>>>>> # file: praxis_be.ldb
>>>>>>>> # owner: HEBI\\user1
>>>>>>>> # group: HEBI\\domain\040users
>>>>>>>> user::rw-
>>>>>>>> user:root:rwx??????????? #effective:r--
>>>>>>>> group::rwx??????????? #effective:r--
>>>>>>>> group:HEBI\\domain\040users:rwx???
#effective:r--
>>>>>>>> group:HEBI\\domain\040computers:r-x???
#effective:r--
>>>>>>>> mask::r--
>>>>>>>> other::---
>>>>>>>>
>>>>>>>>
>>>>>>>> What I've tried:
>>>>>>>>
>>>>>>>> 1. I have set and reset the acl's on the
Linux side for the
>>>>>>>> share and parent dir (the lock file is in the
root of the
>>>>>>>> network share) - and made sure it doesn't
have a mask:
>>>>>>>
>>>>>>> You should stop doing this, as it is a DC, you need
to set the
>>>>>>> permissions from Windows, see here:
>>>>>>>
>>>>>>>
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>>>>>>>
>>>>>>
>>>>>> Thank you for the quick answer. I should have mentioned
that I
>>>>>> tried that as well. Could you confirm if "inherit
acls" and
>>>>>> "create mask" and "directory mask"
should still apply to Samba in
>>>>>> AD mode any more - or not?
>>>>>>
>>>>>>
>>>>> Your share on the DC should only be this:
>>>>>
>>>>> [praxis]
>>>>> path = /srv/samba/praxis
>>>>> read only = No
>>>>>
>>>>> You shouldn't add anything else, it has always been
this way on a DC.
>>>>
>>>> Yes - that's what I read in the docs - and that's what
I started
>>>> with. But that's when I don't get the expected ACL
inheritance. I
>>>> just trimmed the share definition down again to the above, and
when
>>>> I created a dir, the mask kicks in again:
>>>>
>>>> # file: test3
>>>> # owner: root
>>>> # group: HEBI\\domain\040users
>>>> # flags: -s-
>>>> user::rwx
>>>> user:root:rwx??????????? #effective:r-x
>>>> user:3000017:r-x
>>>> group::rwx??????????? #effective:r-x
>>>> group:HEBI\\domain\040users:rwx??? #effective:r-x
>>>> group:HEBI\\domain\040computers:r-x
>>>> mask::r-x
>>>> other::---
>>>> default:user::rwx
>>>> default:user:root:rwx
>>>> default:user:3000017:r-x
>>>> default:group::rwx
>>>> default:group:HEBI\\domain\040users:rwx
>>>> default:group:HEBI\\domain\040computers:r-x
>>>> default:mask::rwx
>>>> default:other::---
>>>>
>>>>
>>>> Is the mask coming from the local Linux filesystem umask? If
yes,
>>>> shouldn't the ACL's supersede it?
>>>>
>>>>> I think it might help if you posted the global part of the
smb.conf
>>>>
>>>> Sure:
>>>>
>>>>
>>>> [global]
>>>> bind interfaces only = Yes
>>>> interfaces = lo eth1 tun0 tun1
>>>> netbios name = HEBI-SERVER
>>>> realm = HEBI.LAN
>>>> server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl,
>>>> winbindd, ntp_signd, kcc, dnsupdate
>>>> workgroup = HEBI
>>>> server role = active directory domain controller
>>>> idmap_ldb:use rfc2307 = yes
>>>> comment >>>>
>>>> log file = /var/log/samba/%m.log
>>>> max log size = 1000
>>>>
>>>> mangling method = hash2
>>>> mangle prefix = 6
>>>> reset on zero vc = yes
>>>> deadtime = 10
>>>>
>>>>
>>>> load printers = yes
>>>> rpc_server:spoolss = external
>>>> rpc_daemon:spoolssd = fork
>>>>
>>> Would it help if I told you that you are reading the wrong
permissions ?
>>
>> That kind of helps, in the sense that I never realised that there are 
>> two sets of ACL's stored in two different places. I have just
re-read
>> for the n-th time the 
>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs 
>> and I'm still trying to get my head around it. I guess that means
the
>> real permissions (seen on the Windows side) are made up of Linux
ACL's
>> *plus* the extended attributes stored by Samba elsewhere?
>>
>> Also, it doesn't quite solve the problem, as the "Domain
Users" still
>> gets no permissions whatsoever when creating new dirs, in spite of the 
>> fact that the parent dir has full permissions for "Domain
Users" (on
>> the Windows side).
> 
> Ok - I might have at least a partial answer. Somehow the default mask in 
> Samba still seems to be obeyed - even in AD mode. It seems to lack by 
> default the 'write' bit - which gets removed from the permissions
when
> creating a new directory. Without any additional share settings in 
> smb.conf, a new subdirectory gets created with the following two sets of 
> permissions, no matter what I try:
> 
> "Domain users" - Traverse, Read attributes, Read extended
attributes -
> This folder only
> "Domain users" - Full Control - Subfolders and files only
> 
> If I add the following settings in smb.conf for the share:
> 
> create mask = 0660
> directory mask = 0770
> 
> Then finally the Windows permissions for a new subdirectory are as 
> expected - just one set for "Domain Users":
> 
> "Domain Users" - Full Control - This folder, subfolders and files
> 
> It seems the the Samba default umask limits the ACL permissions it 
> grants on the Windows side to new files and folders. Could this be a bug 
> - as it doesn't seem to be mentioned anywhere in the docs?
Can anybody confirm if they have seen this behaviour with a Samba AD DC 
with file sharing - where the default smb.conf umask setting (unset in 
smb.conf) limits group ACL's assigned to subfolders - and doesn't grant 
group write privilege - although it should?

On Thu, Jun 13, 2019 at 05:54:39PM +0100, Sebastian Arcus via samba
wrote:
> > > spite of the fact that the parent dir has full permissions for
> > > "Domain Users" (on the Windows side).
> > 
> > Ok - I might have at least a partial answer. Somehow the default mask
in
> > Samba still seems to be obeyed - even in AD mode. It seems to lack by
> > default the 'write' bit - which gets removed from the
permissions when
> > creating a new directory. Without any additional share settings in
> > smb.conf, a new subdirectory gets created with the following two sets
of
> > permissions, no matter what I try:
> > 
> > "Domain users" - Traverse, Read attributes, Read extended
attributes -
> > This folder only
> > "Domain users" - Full Control - Subfolders and files only
> > 
> > If I add the following settings in smb.conf for the share:
> > 
> > create mask = 0660
> > directory mask = 0770
> > 
> > Then finally the Windows permissions for a new subdirectory are as
> > expected - just one set for "Domain Users":
> > 
> > "Domain Users" - Full Control - This folder, subfolders and
files
> > 
> > It seems the the Samba default umask limits the ACL permissions it
> > grants on the Windows side to new files and folders. Could this be a
bug
> > - as it doesn't seem to be mentioned anywhere in the docs?
> 
> Can anybody confirm if they have seen this behaviour with a Samba AD DC
with
> file sharing - where the default smb.conf umask setting (unset in smb.conf)
> limits group ACL's assigned to subfolders - and doesn't grant group
write
> privilege - although it should?
Try setting "obey pam restrictions = false" in [global].
It's set to "true" by default.

I believe the pam calls mess up the umask for smbd, known
bug I think.

On 13/06/19 17:59, Jeremy Allison wrote:
> On Thu, Jun 13, 2019 at 05:54:39PM +0100, Sebastian Arcus via samba wrote:
>>>> spite of the fact that the parent dir has full permissions for
>>>> "Domain Users" (on the Windows side).
>>>
>>> Ok - I might have at least a partial answer. Somehow the default
mask in
>>> Samba still seems to be obeyed - even in AD mode. It seems to lack
by
>>> default the 'write' bit - which gets removed from the
permissions when
>>> creating a new directory. Without any additional share settings in
>>> smb.conf, a new subdirectory gets created with the following two
sets of
>>> permissions, no matter what I try:
>>>
>>> "Domain users" - Traverse, Read attributes, Read extended
attributes -
>>> This folder only
>>> "Domain users" - Full Control - Subfolders and files only
>>>
>>> If I add the following settings in smb.conf for the share:
>>>
>>> create mask = 0660
>>> directory mask = 0770
>>>
>>> Then finally the Windows permissions for a new subdirectory are as
>>> expected - just one set for "Domain Users":
>>>
>>> "Domain Users" - Full Control - This folder, subfolders
and files
>>>
>>> It seems the the Samba default umask limits the ACL permissions it
>>> grants on the Windows side to new files and folders. Could this be
a bug
>>> - as it doesn't seem to be mentioned anywhere in the docs?
>>
>> Can anybody confirm if they have seen this behaviour with a Samba AD DC
with
>> file sharing - where the default smb.conf umask setting (unset in
smb.conf)
>> limits group ACL's assigned to subfolders - and doesn't grant
group write
>> privilege - although it should?
> 
> Try setting "obey pam restrictions = false" in [global].
> It's set to "true" by default.
> 
> I believe the pam calls mess up the umask for smbd, known
> bug I think.
I am on Slackware, and Slackware doesn't use or have pam at all. Do you 
think the above could still be applicable?