[Samba] SaMBa 4.16.4 adds users to ACLs as groups

Thu Jun 15 15:04:15 UTC 2023

Hi Rowland,

 I sadly have no coding experience, so I cannot help by other means than
providing feedback :-( However, I mostly need help, and I'm very thankful
for your efforts.

 So: I know that tdb and rid backends will generate different UIDs and
GIDs, moreover each tdb installation may generate different UID and GID
values. i even know the reason behind this.

 One of my problems is that idmap_rid makes no distinction between users
and groups and you say that it's SaMBa that acts this way in general,
however I found out that on the contrary idmap_tdb makes strict distinction
between users and groups like Unix systems. So, if I'm not mistaken, one of
these idmap backends may have some bugs.

 To be honest I feel incompetent even as an Unix sysadmin, but I'd like to
declare that I'm afraid that these countless POSIX ACLs might cause some
complications for me in the future. I feel worried seeing that just by
saving a Word document, SaMBa adds the owner and owning group of the file
as both users and groups to the file's POSIX ACL despite the fact that
these ACL entries aren't necessary for generating NT ACLs and probably have
no effect on the access of the file, since the standard UNIX rwxrwxrwx bits
are enough for both of these purposes. (Adding users as groups and vice
versa to the POSIX ACL is especially unnecessary and will have no effect on
either the access to the file nor the NT ACL displayed in Windows.)

 By the way, today I conducted even more "experiments": I compared the
current scenario (converting NT ACLs to POSIX ACLs on a best effort basis)
with "vfs objects = acl_xattr \ acl_xattr:ignore system acls = yes" and a
native Windows file server. I found that even with vfs_acl_xattr and native
Windows, the owner of a Word document is the user editing it the last time
(since Word creates a new file for each editing session), but at least the
ACL remains the same. I assume, that Word manipulates the ACL of the file
somehow (at least based on this full_audit output):

Jun 15 12:14:58 fs3 smbd_audit[5168]:
AD\ntamas|192.168.1.1|sys_acl_set_fd|ok|/data/volume1/test/7FC62BB9.tmp
Jun 15 12:14:58 fs3 smbd_audit[5168]:
AD\ntamas|192.168.1.1|sys_acl_set_fd|ok|/data/volume1/test/file1.docx

 But according to my experiences, almost any kind of NT ACL manipulation
leads to excessive ACL data on a SaMBa server with a POSIX ACL based file
system, especially with idmap_rid, where every user is also a group and
every group is also an user. And this might be the cause of the fact that
Word documents edited by multiple users have miles long POSIX ACLs, but
half of the entries of these ACLs have no effect on the access to the file
and the NT ACL displayed on the Windows clients :-(

 But again, thank you for replying and providing help. Sincerely,

Tamás

Rowland Penny via samba <samba at lists.samba.org> ezt írta (időpont: 2023.
jún. 15., Cs, 8:25):

>
>
> 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
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>