[Samba] ACLs, groups and suid-bit?

[Rowland penny]

On 08/09/2020 14:43, Harald Hannelius wrote:
>
> On Tue, 8 Sep 2020, Rowland penny via samba wrote:
>> On 08/09/2020 13:55, Harald Hannelius wrote:
>>>
>>> On Tue, 8 Sep 2020, Rowland penny via samba wrote:
>>>> On 08/09/2020 13:27, Harald Hannelius via samba wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have users in Samba AD with uid- and gidnumbers. I also have 
>>>>> group objects with gidNumbers.
>>>>>
>>>>> I have a Samba member server (all servers Samba 4.9.5-Debian) that 
>>>>> have one share and a lot of directories.
>>>>>
>>>>> The directory permissions are set as a specific group as owner, 
>>>>> and the group write and suid bit are set.
>>>>>
>>>>>  drwxrwsr-x 2 root thegroup  4096 Sep  8 15:25 groupdir
>>>>>
>>>>> This worked fine in Samba 3. However, now when people are storing 
>>>>> files in the dir the file doesn't get group ownership 'thegroup' 
>>>>> nor does it get write permission bit set.
>>>>>
>>>>> Is there a new and improved way to accomplish this now?
>>>>>
>>>>>
>>>> Can we see the smb.conf  from your Unix domain member before we 
>>>> comment.
>>>
>>> [global]
>>>     dedicated keytab file = /etc/krb5.keytab
>>>     disable spoolss = Yes
>>>     kerberos method = secrets and keytab
>>>     load printers = No
>>>     printcap name = /dev/null
>>>     realm = SAD.DOMAIN.COM
>>>     security = ADS
>>>     username map = /etc/samba/user.map
>>>     utmp = Yes
>>>     winbind cache time = 20
>>>     winbind enum groups = Yes
>>>     winbind enum users = Yes
>>>     winbind refresh tickets = Yes
>>>     winbind use default domain = Yes
>>>     workgroup = SAD
>>>     idmap config sad:unix_primary_group = yes
>>>     idmap config sad:unix_nss_info = yes
>>>     idmap config sad:range = 500-4000000
>>>     idmap config sad:schema_mode = rfc2307
>>>     idmap config sad:backend = ad
>>>     idmap config * : range = 5000000-9000000
>>>     idmap config * : backend = tdb
>>>     map acl inherit = Yes
>>>     printing = bsd
>>>     vfs objects = acl_xattr
>>>
>>>
>>> [intra]
>>>     create mask = 0665
>>>     directory mask = 02775
>>>     path = /tftpboot/intra
>>>     read only = No
>>>
>>>
>> Is there some reason you started your uidNumber & gidNumber 
>> attributes at 500 ?
>
> Yes, our users' uidNumber range starts from a little over 500. This is 
> baggage from the 1990's. I don't think Redhat's "start at 1000" was 
> even thought of back then.
Debian was using '1000' long before red-hat decided to change from 
'500', but the problem is, you cannot have any local Unix users.
>
>> The 'new and improved way' is to make use of this:
>>
>> vfs objects = acl_xattr
>
> This doesn't say much to me (reading the man-page of smb.conf). Does 
> it mean to store ACL's in the extra attributes in the underlying 
> filesystem?

Yes, it works like this:

there is the normal Unix 'ugo' permissions

Then there are permissions that can be set with setfacl, these are 
stored in an acl

Finally there are the permissions that are created from Windows which 
are stored  in extended attributes.

>
>> You set the permissions from Windows, try reading this:
>>
>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>
> If I don't have a Windows computer, can I use setfacl or chmod?
You could try setfacl
>
> Can I just stop using ACL's and go back to the old way of reading the 
> permissions from the unix permissions? User's don't know how to, don't 
> have the interest to, or don't want to do this themselves. Nor do I 
> want to manage the ACL's at all, most certainly not through a GUI (on 
> Windows).
No, you are running an AD domain now.
>
> I have to test 'inherit permissions (S)' as well.
>
> What I want is for new files in the directory to have the same (unix) 
> group ownership as the directory has. And that they have write 
> permission for that unix-group.
OK, stop using your group, (which raises a question: you have (unix) 
above, does this mean a group in /etc/group or a group in AD with a 
gidNumber attribute ?), use Domain Users instead, all yours are members 
of Domain Users.

Rowland