[Samba] SaMBa 4.16.4 adds users to ACLs as groups

[Rowland Penny]

On 15/06/2023 16:04, Tamás Németh via samba wrote:
> 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
> 

Hi Tamas, The thing is, is Samba causing the problem, or to put it 
another way, if the share was on a Windows machine, would the ACL's get 
created differently ?

If the ACL's are created differently on Windows share, then there is 
possibly a bug somewhere in the Samba code, but will probably require 
level 10 logfiles and network traces to have any hope of tracking down 
the problem.

Rowland