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?sI suggest you read 'man vfs_acl_xattr' Rowland
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 >
OK, I compared SaMBa 3.2.5 with 4.16.4 and realized that these two versions (and the acl_xattr and acl_tdb VFS modules) show so different behaviours that I have to thoroughly test them before choosing which one to use in production. I'm praying that unwnanted POSIX ACLs won't populate the filesystems too much, or that I will be able to remove them. I still can't figure out why and when SaMBa inserts UIDs amongst GIDs - and vice versa - in POSIX ACLs. Is there a documentation describing the mechanism behind this? I realized that even freshly created Word files have POSIX ACLs, so I compared these new files in four different scenarios. The differences are the following: ##### SaMBa 3.2.5: (Neither the containing directory, nor any of the files have any POSIX ACLs despite the fact that the file system supports them, and "nt acl support" is enabled): fs1-old: # getfacl -RP . # file: . # owner: user_1 # group: smbuser user::rwx group::rwx other::--- # file: ~$file1.docx # owner: user_1 # group: smbuser user::rw- group::rw- other::--- # file: file1.docx # owner: user_1 # group: smbuser user::rw- group::rw- other::--- ##### SaMBa 4.16.4 without any VFS module (only the main file has a POSIX ACL, but the usual unnecessary/erroneous ones): [root at fs3 user_1]# getfacl -RP . # file: . # owner: user_1 # group: domain\040users user::rwx group::rwx other::--- # file: file2.docx # owner: user_1 # group: domain\040users user::rw- user:domain\040users:rw- #group listed as user group::rw- group:domain\040users:rw- #owning group listed unnecessarily(?) with the same permission bits group:user_1:rw- #user listed as group mask::rwx other::--- # file: ~$file2.docx #No POSIX ACLs, and this file gets deleted upon closing the Word document. # owner: user_1 # group: domain\040users user::rw- group::rw- other::--- ##### SaMBa 4.16.4 with acl_xattr (Not only the main file, but also the temporary one has a POSIX ACL): [root at fs3 user_1]# getfacl -RP . # file: . # owner: user_1 # group: domain\040users user::rwx group::rwx other::--- # file: file3.docx # owner: user_1 # group: domain\040users user::rwx user:domain\040users:rwx group::rwx group:domain\040users:rwx group:user_1:rwx mask::rwx other::--- # file: ~$file3.docx #With vfs_acl_xattr this temporary file also has a POSIX ACL, but at least gets deleted upon closing the Word document. # owner: user_1 # group: domain\040users user::rwx user:domain\040users:rwx group::rwx group:domain\040users:rwx group:user_1:rwx mask::rwx other::--- ##### SaMBa 4.16.4 with acl_tdb (2 temporary files this time, one of which is invisible, the other undeletable. All of them have POSIX ACLs): [root at fs3 user_1]# getfacl -RP . # file: . # owner: user_1 # group: domain\040users user::rwx group::rwx other::--- # file: ~$file4.docx #This file is invisible under Windows and won't get deleted upon closing the Word document. # owner: user_1 # group: domain\040users user::rwx user:domain\040users:rwx group::rwx group:domain\040users:rwx group:user_1:rwx mask::rwx other::--- # file: 4EE4085F.tmp #This file also won't get deleted upon closing the Word document. If I delete it in Windows, it disappears, but remains on the Linux filesystem and a refresh/F5 shows it again in Windows. # owner: user_1 # group: domain\040users user::rwx user:domain\040users:rwx group::rwx group:domain\040users:rwx group:user_1:rwx mask::rwx other::--- # file: file4.docx # owner: user_1 # group: domain\040users user::rwx user:domain\040users:rwx group::rwx group:domain\040users:rwx group:user_1:rwx mask::rwx other::--- Thank you in advance, 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 >