[Samba] SaMBa 4.16.4 adds users to ACLs as groups

Fri Jun 9 13:49:19 UTC 2023

 Thank you for the reply. I've read the man page of vfs_acl_xattr and other
man pages. I even installed an empty test server with SaMBa 4.16.4 -
identical to the new server I migrated to - and revived the old SaMBa 3.2.5
server to compare them and examine what happens. The server has millions of
files and tens of thousands of POSIX ACLs (most of which I already know
were "accidentally" created by MS Office in the past decades), so migrating
entirely to "vfs objects = acl_xattr" is probably not an option in the
short term.

 I realized that MS Word can seemingly change the ACL - despite the
disabled "dos filemode" and "acl group control" options - because at first
it creates a new file (with me and my primary group as owning UID and GID
of course) with the contents of the original one, and upon save it removes
the original, and renames the new file, after which it changes the
permissions of the new file to resemble that of the original. (In fact it's
even more complicated, because two additional interim temporary files are
involved). LibreOffice at Linux behaves similarly but without trying to change
the new file's permissions, thus editing a file under Linux will also
create a completely new file but without a POSIX ACL.

 I know, SaMBa tries to convert NT ACLs to POSIX ACLs with best effort, but
during this process it does lot of things I cannot understand yet, like
adding the file's owning group's GID to the POSIX ACL as both UID and GID.
Why? Since it's already the owning group, why is it also added to the ACL?
And especially why does SaMBa add a GID of a group in the ACL as a UID?
That user simply cannot exist in the system! But it also adds the users'
UIDs as GIDs. Again, why?

Original POSIX permission bits of the file:

# file: file.docx
# owner: user_2 #Someone else, not me.
# group: group_2 #A group of the owner I'm not a member of.
user::rw-
group::rw-
other::rw- #I have write access via these bits.

POSIX ACL after I edited the file one time with MS Word:

# file: file.docx
# owner: user_1 #That's me, not the original owner.
# group: domain\040users #My primary group
user::rw-
user:user_1:rw- #Why am I here? I'm already the owner.
user:user_2:rw- #That's the original owning USER.
user:group_2:rw- #That's the original owning GROUP. Why is it added as an
USER?
group::rw-
group:domain\040users:rw- #Why is it here? It's already the owning group.
group:user_2:rw- #That's the original owning USER. Why is it added as an
GROUP?
group:group_2:rw- #That's the original owning GROUP.
mask::rwx
other::rw-

After I edited the file on more time. Interestingly the POSIX ACL changed
again! I only comment the changes:

# file: file.docx
# owner: user_1
# group: domain\040users
user::rw-
user:domain\040users:rw- #My UID was replaced with my primary group's GID
but as an USER
user:user_2:rw-
user:group_2:rw-
group::rw-
group:domain\040users:rw-
group:user_1:rw- #Now my UID is also added as a GID, not only the original
user's
group:user_2:rw-
group:group_2:rw-
mask::rwx
other::rw-

After editing the file with LibreOffice (on Linux, via gvfsd-fuse backend
of KDE)

# file: file.docx
# owner: user_1
# group: domain\040users
user::rw-
group::rw-
other::r--

I also tried editing the NT ACL of a directory in Windows File Explorer.
This is what happened:

POSIX ACLs of a freshly created directory (by me, user_1):

# owner: user_1
# group: domain\040users
user::rwx
group::rwx
other::---

After granting write privilege to user_2 (and doing nothing else):

# file: directory_name
# owner: user_1
# group: domain\040users
user::rwx
user:domain\040users:rwx #GID added as UID. Why? This user is clearly
nonexistent.
user:user_2:rwx #This is the only permission I actually wanted to grant.
group::rwx
group:domain\040users:rwx #Again, the owning group is "manually" added to
the ACL, too.
group:user_1:rwx #UID added as GID. This group does not exist on the system.
group:user_2:rwx #UID added as GID. This group does not exist on the system.
mask::rwx
other::---

 So my question is, why does SaMBa add the owning user and group to the
POSIX ACL in spite that these entities already have access via the POSIX
user and group bits? And more importantly: Why does SaMBa add UIDs as GIDs
and vice versa, when these users and groups clearly don't exist on the
system?

Thank you in advance,

NÉMETH, Tamás

Rowland Penny via samba <samba at lists.samba.org> ezt írta (időpont: 2023.
jún. 7., Sze, 18:57):

>
>
> On 07/06/2023 17:44, Tamás Németh via samba wrote:
> > Dear All,
> >
> >   Thank you for your help (especially Rowland Penny), I finally managed
> to
> > migrate our ancient ext3 based, ISO-8859-2 encoded SaMBa 3.2.5 with
> locally
> > stored UIDs and GIDs to a UTF-8 encoded ex4 based server running SaMBa
> > 4.16.4 with RID UID/GID backend.
> >
> >   However, after two weeks of the migration I observed something
> horrible:
> > Windows Word (or MS Office in general) somehow manages to chown every
> saved
> > file to the acting user, putting the original owner to a POSIX ACL. It
> > means that slowly every user ever editing that document will be
> accumulated
> > in its POSIX ACL. Not only MS Office, but the gvfsd-fuse backend of KDE
> > does some horror: It also manages to chown a file it has write access to
> > only via the "other (users)" POSIX bits, but the instead of adding users
> to
> > the POSIX ACL, it removes the access from the "other (users)" bits.
> >
> >   OK, let's assume it's not a bug, but a feature (
> >
> https://superuser.com/questions/1491076/disable-word-from-creating-acls-on-samba-fileshare
> > or
> >
> https://superuser.com/questions/289866/how-do-i-avoid-changing-a-files-linux-permissions-when-saving-over-a-samba-conn
> > ). But if so, what is the recommended solution to prevent SaMBa from
> > letting programs - intended only to write the content of files - change
> > permissions in addition? Shoud I really simply disable "nt acl support"?
> >
> >
> >   But even when considering this a feature, the newer SaMBa (4.16.4) does
> > something, I can only consider being a bug: It needlessly adds the owning
> > group to the POSIX ACL upon saving by MS Word, and additionally it adds
> > users (except the acting user) to the POSIX ACL as GROUPS!!! It means
> there
> > are NONEXISTENT groups added to the POSIX ACL which have the same GIDs as
> > the UIDs of the users in the ACL:
> >
> > # file: file.docx
> > # owner: user_1
> > # group: domain\040users
> > user::rw-
> > user:domain\040users:rw-
> > user:user_2:rw-
> > user:user_1:rw-
> > group::rw-
> > group:domain\040users:rw-  #This is unnecessary, since it equals the
> owning
> > group. SaMBa 3.2.5 doesn't add this.
> > group:user_2:rw- #This is not only unnecessary, but also nonexistent.
> This
> > is a UID not a GID!
> > mask::rwx
> > other::rw-
> >
> >   I also observed that UIDs are erroneously added as groups to the POSIX
> ACL
> > by SaMBa 4.16.4 when manually adding users to the NT ACL with file
> explorer
> > (by editing permissions), not only by saving with MS Word. I assume this
> > means that Word only wants to add UIDs to the ACL but because of some
> bug,
> > SaMBa 4.16.4 duplicates every UID as GID (except the acting user's) when
> > adding it to a POSIX ACL. Do you consider it a bug, and if so, is it
> > already known, or unknown? Is there any fix or workaround?
> >
> > Thank you for your answer,
> >
> > NÉMETH, Tamás
>
> I suggest you read 'man vfs_acl_xattr'
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>