[Samba] icacls 'DENY' and Unix user execute bit

cn at brain-biotech.de cn at brain-biotech.de
Sun Nov 21 05:55:39 UTC 2021


At least I think I know why it User to work for on centos7.  You probably used smb1 (with Unix extensions). Now smb1 is mostly disabled (and shouldn't be).

I am sorry but at least I do not know how to fix this. 
Have you shown us your mount options on Linux that you use?

Regards


Am 20. November 2021 18:36:48 MEZ schrieb Ken Bass via samba <samba at lists.samba.org>:
>On 11/20/21 4:25 AM, Rowland Penny via samba wrote:
>> On Fri, 2021-11-19 at 19:00 -0500, Ken Bass via samba wrote:
>>>> 
>>> Hi Rowland,
>>> 
>>> On the SERVER side:
>>> 
>>> -rwxrwx---+ 1 user testshare users 16 Nov 19 16:11 test.txt
>> Yes, you are using ACL's, note the '+' at the end of the Unix
>> permissions.
>> 
>> What does 'getfacl test.txt' produce ?
>> 
>>> On the CLIENT side, where this share is mounted via cifs in
>>> /etc/fstab
>>> 
>>> -rwxrw---- 1 user testshare users 16 Nov 19 16:11 test.txt
>> However, the cifs mounted share doesn't seem to be using using ACL's
>
>It has cifsacl in the /etc/fstab, so I don't know why.
>
>>> And reproducing the issue - on the CLIENT side
>>> 
>>> /usr/bin/getcifsacl test.txt
>>> REVISION:0x1
>>> CONTROL:0x8004
>>> OWNER:MYDOM\user
>>> GROUP:MYDOM\Testshare Users
>>> ACL:MYDOM\user:ALLOWED/0x0/FULL
>>> ACL:MYDOM\Testshare Users:ALLOWED/0x0/FULL
>>> ACL:\Everyone:ALLOWED/0x0/
>>> 
>>> And after running
>>> 
>>> chmod u-x test.txt
>> I wouldn't recommend running chmod against anything that has an ACL set
>> on it, it will probably remove or change the ACL.
>
>I personally am not running chmod other than for troubleshooting, but the Linux application that writes to the files on the share clears that execute bit when it updates/modifies files.
>So I am stuck with that.
>
>>> -rw-rw---- 1 user testshare users 16 Nov 19 16:12 test.txt
>>> 
>>> /usr/bin/getcifsacl test.txt
>>> REVISION:0x1
>>> CONTROL:0x8004
>>> OWNER:MYDOM\user
>>> GROUP:MYDOM\Testshare Users
>>> ACL:MYDOM\user:DENIED/0x0/0xd0130
>>> ACL:MYDOM\user:ALLOWED/0x0/0x1f01df
>>> ACL:MYDOM\Testshare Users:ALLOWED/0x0/FULL
>>> ACL:\Everyone:ALLOWED/0x0/0x40
>>> 
>>> Notice after running the chmod to remove the user exec permission,
>>> the
>>> DENIED ACL is added.
>>> 
>>> That DENIED ACL does not just remove 'execution', but as I
>>> originally
>>> posted:
>>> 
>>> test.txt MYDOM\user:(DENY)(D,WDAC,WO,WEA,X,WA)
>>>            MYDOM\user:(R,W,D,WDAC,WO,DC)
>>>            MYDOM\Testshare Users:(F)
>>>            Everyone:(DC)
>>> 
>>> it appears to also remove WEA - Write extended attributes, WA -
>>> Write
>>> attributes, WO - Write owner.
>>> 
>>> My guess is that is why trying to write to test.txt from Windows
>>> after
>>> the chmod results in Access Denied. That DENY clause prevents
>>> Windows
>>> from doing that.
>> Your problem appears to be that you are trying to fix your problem an
>> hammer.
>
>I don't follow. I am just trying to understand why it is behaving the way it is.
>
>>   
>>> # Global parameters
>>> [global]
>>>       disable spoolss = Yes
>>>       guest account = guestuser
>>>       interfaces = lo 192.168.2.0/24
>>>       kerberos method = secrets and keytab
>>>       load printers = No
>>>       log file = /var/log/samba/%m.log
>>>       map to guest = Bad User
>>>       printcap name = /dev/null
>>>       realm = MYDOM.LOCAL.NET
>>>       security = ADS
>>>       server string = myserver
>>>       template homedir = /home/%U
>>>       template shell = /bin/bash
>>>       username map = /etc/samba/user.map
>> What exactly is in the 'user.map' ?
>
>!root = MYDOM\Administrator MYDOM\administrator
>
>
>> 
>>>       winbind enum groups = Yes
>>>       winbind enum users = Yes
>>>       winbind refresh tickets = Yes
>>>       winbind use default domain = Yes
>>>       workgroup = MYDOM
>>>       idmap config mydom : unix_primary_group = yes
>>>       idmap config mydom : range = 1000-29999
>> I suppose you realise that using that range means you cannot have any
>> local Unix users.
>
>Correct. I could/should probably make it start at 1001 since I normally create a 'local' user when initially setting up a system. But other than the initial root user install/configuration, all users comes from the AD.
>
>>>       idmap config mydom : schema_mode = rfc2307
>>>       idmap config mydom : backend = ad
>>>       idmap config * : range = 30000-39999
>>>       idmap config * : backend = tdb
>>>       cups options = raw
>>>       hosts allow = 127. 192.168.2.
>>>       map acl inherit = Yes
>>>       printing = bsd
>>>       strict allocate = Yes
>>>       vfs objects = acl_xattr
>>> 
>>> [TestShare]
>>>       comment = TestShare
>>>       create mask = 0770
>>>       directory mask = 0770
>>>       force create mode = 0770
>>>       force directory mode = 0770
>>>       force group = "TestShare Users"
>>>       path = /mnt/store/TestShare
>>>       read only = No
>> I suggest you change the share to this:
>> 
>> [TestShare]
>>       comment = TestShare
>>       path = /mnt/store/TestShare
>>       read only = No
>> 
>> Then set the permissions from windows and only windows.
>> 
>> Try reading:
>> man mount.cifs
>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>> 
>> Rowland
>> 
>> 
>> 
>
>I don't think that is going to work since I cannot control that the Linux application is messing with permissions. When files are created under Linux, the execute bit is typically not set.
>So to support an application that can run on Windows and on Linux against the same share I need a solution that will work.
>
>Further testing...
>
>On the server side, I removed
>
>vfs objects = acl_xattr
>map acl inherit = Yes
>
>On the client side, I kept the cifsacl.
>
>I found that if I 'chmod u-x test.txt', it removes BOTH wx user attribute on the server making the file read-only on the server. That does not seem right.
>
>Next test, on the client side, I removed the cifsacl option, added uid,gid to the mount.cifs and it works fine.
>
>Looking at my old Centos 7 setup, it looks like I did not use the acl_xattr.
>
>-- 
>To unsubscribe from this list go to the following URL and read the
>instructions:  https://lists.samba.org/mailman/options/samba

-- 
Dr. Christian Naumer
Vice President
Unit Head Bioprocess Development

BRAIN Biotech AG
Darmstaedter Str. 34-36, D-64673 Zwingenberg
e-mail cn at brain-biotech.com, homepage www.brain-biotech.com
phone +49-6251-9331-30 / fax +49-6251-9331-11

Sitz der Gesellschaft: Zwingenberg/Bergstrasse
Registergericht AG Darmstadt, HRB 24758
Vorstand: Adriaan Moelker (Vorstandsvorsitzender), 
Lukas Linnig
Aufsichtsratsvorsitzender: Dr. Georg Kellinghusen


More information about the samba mailing list