[Samba] Cleanup permission settings / traverse folder

[Thomas Hoffmann (Speed4Trade GmbH)]

> -----Ursprüngliche Nachricht-----
> Von: samba <samba-bounces at lists.samba.org> Im Auftrag von Rowland Penny
> via samba
> Gesendet: Montag, 20. März 2023 20:28
> 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 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
> >>> o+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=6c95e467817b246a0ea
> >> b626cac10b6120f6c88f8
> >>
> >> 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
> 

I am not sure if the naming Windows uses is very meaningful.
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking gives some insights.
Strangely, the permission to bypass traversal check is named "SeChangeNotifyPrivilege" (maybe an accident in naming?)
The fact that this windows policy is applied to every authenticated user per default and samba behaves the opposite, made me struggle for a long time today.
On windows you can activate / deactivate this feature.

If this feature is not supported by Samba or the underlying POSIX-system, I can deal with it. 
I just couldn’t find any documentation about this behavior and I was not sure, if I just missed something.
Maybe a hint in the documentation about this difference would be nice, especially if you come from the windows world, it is a surprising fact.