Dear Ralph and Rowland, OK, I've made some experiments to figure out if it's really a difference between SaMBa 4.6.5 and 4.16.4, but it's not. It's the difference between idmap backends idmap_tdb and idmap_rid! As I mentioned earlier, using different vfs_acl_* modules leads to different POSIX ACLs ( https://lists.samba.org/archive/samba/2023-June/245479.html ). Is it REALLY intentional? However, now I realized that using different idmap backends also leads to different NSS user/group resolutions which is probably even more weird. First I tried idmap_rid with SaMBa 4.16.4 and I observed that libnss_winbind is willing to resolve any user/group name to UID/GID and vice versa entirely disregarding the type (user of group) of the entity: [root at fs1 temp]# getent passwd administrator administrator:*:10500:10513::/home/WS1/administrator:/bin/false [root at fs1 temp]# getent passwd 10500 administrator:*:10500:10513::/home/WS1/administrator:/bin/false [root at fs1 temp]# getent group administrator administrator:x:10500:administrator [root at fs1 temp]# getent group 10500 administrator:x:10500:administrator [root at fs1 temp]# getent group 'domain admins' domain admins:x:10512:administrator,admin [root at fs1 temp]# getent group 10512 domain admins:x:10512:administrator,admin [root at fs1 temp]# getent passwd 'domain admins' domain admins:*:10512:10512::/home/WS1/domain admins:/bin/false [root at fs1 temp]# getent passwd 10512 domain admins:*:10512:10512::/home/WS1/domain admins:/bin/false As a Linux sysadmin I don't like this "feature", or I'd like to have it optional at least, because I'd like to keep file permissions and ownerships as UNIX-like as possible. However, after changing to idmap_tdb (still under SaMBa 4.16.4), I realised that libnss_winbind behaves the way I expect it (which means users and groups are clearly distinct types of entities): [root at fs3 ntamas]# getent passwd administrator administrator:*:1102:1106::/home/WS1/administrator:/bin/false [root at fs3 ntamas]# getent passwd 1102 administrator:*:1102:1106::/home/WS1/administrator:/bin/false [root at fs3 ntamas]# getent group administrator [root at fs3 ntamas]# getent group 1102 [root at fs3 ntamas]# chgrp administrator file.txt chgrp: invalid group: ?administrator? [root at fs3 ntamas]# setfacl -m g:administrator:r file.txt setfacl: Option -m: Invalid argument near character 3 [root at fs3 ntamas]# getent group 'domain admins' domain admins:x:1112:admin,administrator [root at fs3 ntamas]# getent group 1112 domain admins:x:1112:admin,administrator [root at fs3 ntamas]# getent passwd 'domain admins' [root at fs3 ntamas]# getent passwd 1112 [root at fs3 ntamas]# chown 'domain admins' file.txt chown: invalid user: ?domain admins? [root at fs3 ntamas]# setfacl -m 'u:domain admins:r' file.txt setfacl: Option -m: Invalid argument near character 3 This is what I'd like to have using idmap_rid! However, POSIX ACLs of freshly created Office files are still verbose/redundant for my taste. For example I created a txt file using only File Explorer and a docx file using Word. The two files effectively have the same permission settings which are converted to the same NT ACLs shown in File Explorer on Windows, but the docx file has some seemingly unnecessary redundancies. It would be nice to at least have an option in SaMBa to eliminate these redundancies before converting them to POSIX ACLs (since they aren't shown upon reverse conversion anyway). So, these are the differences: # file: newfile.docx #This file has a (probably unnecessary) POSIX ACL # owner: user_1 # group: domain\040users user::rw- user:user_1:rw- #I'm already the owning user having the same permissions. Why am I also explicitly added to the POSIX ACL? group::rw- group:domain\040users:rw-- #It's already the owning group having the same permissions. Why is it also explicitly added to the POSIX ACL? mask::rwx #Shouldn't it only be rw? other::--- # file: newfile.txt #No POSIX ACL here :-) # owner: user_1 # group: domain\040users user::rw- group::rw- other::--- However, it's still better IMHO that with idmap_rid, where all accessing UIDs and GIDs (including the owning ones) are also explicitly added to the POSIX ACL as BOTH users and groups, which produces great amounts of unnecessary POSIX ACL entries and not even remaining consistent when changing the underlying vfs_acl_* module ( https://lists.samba.org/archive/samba/2023-June/245479.html ). It would also be nice to have at least an option for data cleansing of permission settings before saving them to POSIX ACLs in order not to have ACEs not converted into NT ACL entries and being ineffective on the UNIX file system. For example it would be nice to assign the exclusive access to a newly created Word document by simply using chown and not having to remove or edit an unnecessarily (at least from the POV from an UNIX sysadmin) generated POSIX ACL. Is there already such a POSIX ACL simplifying option in smb.conf? Thank you in advance, Tam?s Ralph Boehme <slow at samba.org> ezt ?rta (id?pont: 2023. j?n. 13., K, 11:03):> Hi! > > On 6/13/23 00:57, Tam?s N?meth via samba wrote: > > But why does SaMBa 4.16.4 do what is does, when back then SaMBa 4.6.5 > > didn't do it yet? > > hm, afair this should have worked that way in 4.6.5 as well. If it > didn't, that was probably a bug. > > The reason for this feature, is that this allows storing Windows groups > as file owner as well Windows to Linux identity mapping type to change > from user to group which happens as part of SID history. > > -slow > > -- > Ralph Boehme, Samba Team https://samba.org/ > SerNet Samba Team Lead https://sernet.de/en/team-samba > SAMBA+ Samba packages https://samba.plus/ > >
On 14/06/2023 17:48, Tam?s N?meth via samba wrote:> Dear Ralph and Rowland, > > OK, I've made some experiments to figure out if it's really a difference > between SaMBa 4.6.5 and 4.16.4, but it's not. It's the difference between > idmap backends idmap_tdb and idmap_rid! As I mentioned earlier, using > different vfs_acl_* modules leads to different POSIX ACLs ( > https://lists.samba.org/archive/samba/2023-June/245479.html ). Is it REALLY > intentional? > > However, now I realized that using different idmap backends also leads to > different NSS user/group resolutions which is probably even more weird. > First I tried idmap_rid with SaMBa 4.16.4 and I observed > that libnss_winbind is willing to resolve any user/group name to UID/GID > and vice versa entirely disregarding the type (user of group) of the entity: >Hi Tamas, Getting different ID's from different idmap backends is to be expected, because they all work differently, The 'tdb' backend is an allocating backend. The 'ad' backend requires the admin to supply uidNumber & gidNumber attributes. The 'rid' backend calculates the ID's from the Windows RID. The 'autorid' backend works similarly to the 'rid' backend, but is meant for multiple domains and you will get different ID's compared with the 'rid' backend. There are other idmap backends, but they all work differently. I cannot recommend using the 'tdb' backend for the main AD domain, I am not saying that it will not work, but there will be one big problem. As I said, 'tdb' is an allocating backend, this means that as a user or group connects to Samba, it is given an ID, which it retains, so far so good. However, if you create a new Samba server using exactly the same global smb.conf , you will not get the same ID's for the users & groups. There is a prime example of this on Samba AD DC's, where idmap.ldb (another allocating backend, only used on DC's) has to be synced between DC's to keep the same ID's. What does this mean in practice ? Well, in my opinion, it means that you cannot reliably back up your data, you can back it up, but you cannot rely on what you backup belonging to the correct people if you restore it. As Ralph pointed out, groups becoming users is all a feature of Windows, where groups can and do own files and folders. Samba in AD mode is trying its hardest to emulate Windows AD, so I do not expect Samba to break this feature. That isn't to say that Samba might not 'bend' the feature for Unix computers, say by providing parameters in smb.conf that turn off certain things on Samba machines, but this will require code, which means time and that, usually, means money. If you feel that you have the coding experience and could write the required code, then patches will always be welcome. Rowland
Am Mittwoch, dem 14.06.2023 um 18:48 +0200 schrieb Tam?s N?meth via samba:> # file: newfile.docx????????????????????? #This file has a (probably > unnecessary) POSIX ACL > # owner: user_1 > # group: domain\040users > user::rw- > user:user_1:rw-??????????????????????????? #I'm already the owning user > having the same permissions. Why am I also explicitly added to the POSIX > ACL? > group::rw- > group:domain\040users:rw--??????? #It's already the owning group having the > same permissions. Why is it also explicitly added to the POSIX ACL? > mask::rwx #Shouldn't it only be rw? > other::---This has nothing to to with Samba if ACLs are enabled and the directory has some default ACLs this also happens if you create the file on the server via ssh or on the cli. At least this is the case for me. Regards Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <http://lists.samba.org/pipermail/samba/attachments/20230615/66a7ac27/signature.sig>