[Samba] Permissions not inherited when moving a file

Sören Busse soeren.busse at magis.school
Tue Aug 6 14:36:45 UTC 2019


Thank you very much for your reply.

Beside the fact that we can't use Windows ACLs because we need the posix 
acls for a different service,

are you sure, that Windows ACLs would fix this issue? The ntacls are 
stored in the xattr of the file itself. When you now move the file to a 
different location the xattr should stay the same and the user still 
doesn't have the right permissions to that file.

Aren't there any other solutions when using Posix ACLs?

Kind regards
Sören Busse

Am 06.08.19 um 16:23 schrieb Rowland penny via samba:
> On 06/08/2019 15:02, Sören Busse via samba wrote:
>> Thank you very much for your reply.
>>
>> Oh sorry, I forgot that:
>> Here's my smb.conf for Samba 4.9.4-Debian fileserver. I'm running 
>> samba with a different Samba-DC (i replaced my domain with samdom):
>>
>> [global]
>> security = ADS
>> workgroup = samdom
>> realm = samdom.domain.tld
>> log file = /var/log/samba/%m.log
>> log level = 1
>> idmap config * : backend = tdb
>> idmap config * : range = 3000-7999
>> idmap config samdom : backend = rid
>> idmap config samdom : range = 100000-200000
>> winbind nss info = template
>> template shell = /bin/bash
>> template homedir = /home/%U
>> username map = /etc/samba/user.map
>>
>>
>> [Share]
>> path = /srv/Share
>> read only = no
>> store dos attributes = no
>> create mask = 0770
>> force create mode = 0770
>> directory mask = 0770
>> force directory mode = 0770
>> hide files = /desktop.ini/.BIN/
>>
>> smb.conf for Domain Controller:
>> [global]
>>     bind interfaces only = Yes
>>     dns forwarder = 10.10.0.1
>>     interfaces = lo enp3s0
>>     netbios name = DC-1
>>     realm = SAMDOM.DOMAIN.TLD
>>     server role = active directory domain controller
>>     workgroup = SAMDOM
>>     idmap_ldb:use rfc2307 = yes
>>
>> [netlogon]
>>     path = /var/lib/samba/sysvol/samdom.domain.tld/scripts
>>     read only = No
>>
>> [sysvol]
>>     path = /var/lib/samba/sysvol
>>     read only = No
>>
>> Thank you very much in advance
>> Kind regards
>> Sören Busse
>>
>> Am 06.08.19 um 15:45 schrieb Rowland penny via samba:
>>> On 06/08/2019 14:22, Sören Busse via samba wrote:
>>>> Hello Samba list subscribers,
>>>>
>>>> i have a permission issue when moving files or directories (rename 
>>>> syscall) between directories with different permissions in my share.
>>>> I'm using POSIX ACLs on my shares.
>>>>
>>>> These are my users:
>>>> user.one (uid: 101111, gid: 101111)
>>>> SAMDOM\Domain Users (gid: 100513)
>>>>
>>>> I've got the following directories:
>>>>
>>>> This is the private (home) directory of user.one. The user is the 
>>>> user owner and group owner and has full permissions (770)
>>>>
>>>> # file: Users/user.one/
>>>> # owner: 101111
>>>> # group: 101111
>>>> # flags: -s-
>>>> user::rwx
>>>> group::rwx
>>>> mask::rwx
>>>> other::---
>>>> default:user::rwx
>>>> default:group::rwx
>>>> default:mask::rwx
>>>> default:other::---
>>>>
>>>> This user also has a public directory where only the user is able 
>>>> to write files and all other users in this domain should only be 
>>>> able to read the files:
>>>> Whenever the user creates a file in there all "Domain Users 
>>>> (100513)" will only have read permissions to the files because of 
>>>> the default acls.
>>>>
>>>> # file: Public/user.one/
>>>> # owner: 101144
>>>> # group: 100513
>>>> # flags: -s-
>>>> user::rwx
>>>> group::r-x
>>>> mask::r-x
>>>> other::---
>>>> default:user::rwx
>>>> default:group::r-x
>>>> default:mask::r-x
>>>> default:other::---
>>>>
>>>>
>>>> This works absolutely fine when copying or creating files.
>>>> However when the user moves a file from the private directory 
>>>> (Users/user.one) with the following permissions:
>>>>
>>>> # file: Users/user.one/test
>>>> # owner: 101111
>>>> # group: 101111
>>>> user::rwx
>>>> group::rwx
>>>> mask::rwx
>>>> other::---
>>>>
>>>> to the public directory the permissions stay the SAME. This will 
>>>> practically prevent any user from reading the file, because the 
>>>> move (or rename syscall) doesn't inherit the default acls. I find 
>>>> this behavior very unexpected although it makes totally sense from 
>>>> the file systems point of view.
>>>>
>>>> The main question now is: How to solve this problem?
>>>>
>>>> Here are some ideas I had:
>>>> 1. Samba should apply the posix acls from the parent directory 
>>>> automatically after a rename like it is done with the archive bit. 
>>>> This feature should be off by default and can be enabled in the 
>>>> configuration.
>>>> https://github.com/samba-team/samba/blob/master/source3/smbd/reply.c#L7055 
>>>>
>>>>
>>>> 2. Use an external service which watches directory movements and 
>>>> then apply the permissions recursively.
>>>> 2.1 Inotify: It would be possible to use inotify. The main 
>>>> disadvantage is the lack of automatic recursive watchers. So your 
>>>> external service needs to create a separate watch for every 
>>>> directory which might be quite performance intensive when your 
>>>> share has multiple 100.000 directories (e.g. when some users 
>>>> develop nodejs applications with it's thousands of dependencies).
>>>> 2.2 Fanotify: It was updated with kernel 5.1 and now supports 
>>>> notifications for file movements. 
>>>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-Fanotify-Improvements 
>>>>
>>>> This however doesn't work with multiple namespaces which is a must 
>>>> for our use case (docker).
>>>>
>>>> So how do you mitigate this problem in your environment? I think 
>>>> this scenario isn't so special that some other users wouldn't have 
>>>> the same issue.
>>>>
>>>> I would appreciate any advice or tips how to solve this problem.
>>>>
>>>> Kind regards
>>>> Sören Busse
>>>>
>>> Lets start with seeing your smb.conf, so we can see how you are 
>>> running Samba.
>>>
>>> Rowland
>>>
>>>
>>>
>>
> I would suggest you use Windows ACLs instead, try reading this:
>
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>
> Rowland
>
>
>



More information about the samba mailing list