[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 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.