[Samba] Cleanup permission settings / traverse folder

[Rowland Penny]

On 20/03/2023 19:21, Jeremy Allison wrote:
> On Mon, Mar 20, 2023 at 07:12:22PM +0000, Rowland Penny via samba wrote:
>>
>>
>> On 20/03/2023 18:26, Thomas Hoffmann (Speed4Trade GmbH) via samba wrote:
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: samba <samba-bounces at lists.samba.org> Im Auftrag von Rowland Penny
>>>> via samba
>>>> Gesendet: Montag, 20. März 2023 18:27
>>>> An: samba at lists.samba.org
>>>> Cc: Rowland Penny <rpenny at samba.org>
>>>> Betreff: Re: [Samba] Cleanup permission settings / traverse folder
>>>>
>>>>
>>>>
>>>> On 20/03/2023 16:58, Rowland Penny via samba wrote:
>>>>>
>>>>>
>>>>> On 20/03/2023 16:22, Thomas Hoffmann (Speed4Trade GmbH) via samba
>>>> wrote:
>>>>>> Hello,
>>>>>> I have problems removing the permission settings on a
>>>>>> directory/folder after configuration of a share.
>>>>>>
>>>>>> My folders look like:
>>>>>> /var/folder1/folder2/
>>>>>>
>>>>>> I created share1 on folder1 and share2 on folder2.
>>>>>> Afterwards, I activated ACLs and set permission on folder1 to
>>>>>> domain/group1 and on folder2 to domain/group2.
>>>>>>
>>>>>> I couldn't access share2 with a user from group2 and I figured out
>>>>>> that Samba doesn't support SeChangeNotifyPrivilege  (bypass traverse
>>>>>> checking).
>>>>>
>>>>> According to 'net rpc rights list' it does, but it is described as
>>>>> 'Register for change notify', however, in previous documentation it
>>>>> was described as 'Bypass traverse checking'. I do not know when the
>>>>> description changed or why.
>>>>>
>>>>>> Because user2 from group2 doesn't have any permissions on folder1,
>>>>>> the user can't access folder2 and therefore can't access share2.
>>>>>>
>>>>>> So far, so good. I decided to remove share1 because it was only a
>>>>>> share for convenience. Afterwards I deleted the ACLs on folder1 with
>>>>>> "setfacl -bn /var/folder1/"
>>>>>> Unfortunately, user2 still can't access share2. Somehow folder1 is
>>>>>> still blocking user2 to access folder2.
>>>>>> When I create folder2 somewhere else with the exact same settings,
>>>>>> everything works.
>>>>>> Does samba store some permissions at another place? How to tidy up
>>>>>> the settings on folder1 properly?
>>>>>> Any hints would be appreciated. Thanks!
>>>>>> I can provide smb-settings if needed.
>>>>>
>>>>> Please post the output of 'testparm -s' (sanitised if required) and
>>>>> the permissions set on the share.
>>>>>
>>>>> Rowland
>>>>>
>>>>>
>>>>
>>>> Then after a bit of investigation, I turned up this smb.conf parameter:
>>>>
>>>> honor change notify privilege
>>>>
>>>> Which by default is set to 'no', try adding the parameter but set to 
>>>> 'yes' i.e.
>>>>
>>>> honor change notify privilege = yes
>>>>
>>>> restart or reload Samba and see if that helps
>>>>
>>>> You may also have to give the user the privilege using 'net'
>>>>
>>>> Rowland
>>>>
>>>
>>>
>>> Unfortunately, the "honor change notify privilege = yes" didn’t show 
>>> any effects.
>>> Also granting SeChangeNotifyPrivilege to the user2 and group2 didn’t 
>>> help. Access to share2 is still denied.
>>>
>>> Here is the output of testparam -s
>>>
>>> Load smb config files from /etc/samba/smb.conf
>>> Loaded services file OK.
>>> Weak crypto is allowed
>>>
>>> Server role: ROLE_STANDALONE
>>>
>>> # Global parameters
>>> [global]
>>>         config file = /etc/samba/smb.s4t.conf
>>>         log file = /var/log/samba/log.%m
>>>         logging = file
>>>         map to guest = Bad User
>>>         max log size = 1000
>>>         obey pam restrictions = Yes
>>>         pam password change = Yes
>>>         panic action = /usr/share/samba/panic-action %d
>>>         passwd chat = *Enter\snew\s*\spassword:* %n\n 
>>> *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>>>         passwd program = /usr/bin/passwd %u
>>>         server role = standalone server
>>>         server string = %h server (Samba, Ubuntu)
>>>         unix password sync = Yes
>>>         usershare allow guests = Yes
>>>         workgroup = xxx
>>>         idmap config * : backend = tdb
>>>
>>> The share config looks like:
>>>
>>> [share2]
>>>    comment = share2
>>>    path = /var/folder1/folder2/
>>>    guest ok = no
>>>    read only = no
>>>    browsable = yes
>>>    map archive = no
>>>    inherit permissions = yes
>>>    # enable windows acls
>>>    vfs objects = acl_xattr
>>>    map acl inherit = yes
>>>    # acl_xattr:ignore system acls = yes
>>>    honor change notify privilege = yes
>>>
>>> I figured out that in order to access folder2, the folder1 must have 
>>> o+x. Otherwise, folder2 can't be accessed by user2 even if the ACL of 
>>> folder2 allows it.
>>> So it seems it boils down to the traverse problem.
>>
>> I have done a bit more investigation and found this patch that Volker 
>> produced:
>>
>> https://lists.samba.org/archive/samba-technical/2018-November/131158.html
>>
>> This didn't seem to make it to Samba, but there were changes here:
>>
>> https://git.samba.org/?p=samba.git;a=commitdiff;h=6c95e467817b246a0eab626cac10b6120f6c88f8
>>
>> The smb.conf parameter I referred to, is supposed to allow a user to 
>> receive all requested notify results, even if they do not have 
>> permissions.
>>
>> So, if you have given the user (on the computer where the share is 
>> stored) the required privilege, the user should be able to traverse to 
>> the share, this is my understanding of the situation.
>> If this isn't the case, then you could have found a bug, but wiser 
>> heads than mine will have to check this.
> 
> Access to the directory isn't the same as the change notify
> perms. Just giving the privilege won't override the base-OS
> security checks on traverse.
> 
> Bottom line - POSIX by default enforces traverse permission ('x') needed
> on a directory, Windows does not. The user right in Windows is:
> 
> Bypass traverse checking
> 
> which on Windows by default is granted to "Everyone". It
> essentially implicitly adds the 'x' bit (in POSIX terms)
> to every directory within a component path - Windows separates
> out the 'traverse directory' functionality from the 'list directory
> contents', POSIX does not.

If I understand you correctly, the SeChangeNotifyPrivilege can never 
work the same on Linux as it does on Windows, where it seems users with 
the privilege can walk the path even if they don't actually have 
permission to do so (according to the ACL's).

Rowland