Hm.... Very, very interesting. I tried with SaMBa 4.16.4, and realized that
the NSS module winbind is willing to resolve any user or group name to
both UID and GID upon direct request. Why? Isn't this a bug? For example:
[root at fs3 ~]# getent passwd ntamas
ntamas:*:11950:10513::/home/WS1/ntamas:/bin/false
[root at fs3 ~]# getent group ntamas
ntamas:x:11950:ntamas
#But there is no group named ntamas, so why does this happen?:
[root at fs3 ~]# getent group | grep ^ntamas:
[root at fs3 ~]#
[root at fs3 ~]# getent group 'domain admins'
domain admins:x:10512:admin,administrator
[root at fs3 ~]# getent passwd 'domain admins'
domain admins:*:10512:10512::/home/WS1/domain admins:/bin/false
#And there is no user named 'domain admins':
[root at fs3 ~]# getent passwd | grep 'domain admins:'
[root at fs3 ~]#
I also have a SaMBa 4.9.5 member server which doesn't automatically
generate GIDs from usernames and UIDs from groupnames:
root at rt:~# getent group ntamas
root at rt:~# getent passwd 'domain admins'
root at rt:~#
But why does SaMBa 4.16.4 do what is does, when back then SaMBa 4.6.5
didn't do it yet? Anyway, it's too late to revert to and older version,
as
4.16.4 already runs with business critical data in millions of files, but
I'd like to prevent it from endlessly producing needless (at least from my
point of view) POSIX ACLs.
And again: Many-many thanks for your efforts in helping us!
Rowland Penny via samba <samba at lists.samba.org> ezt ?rta (id?pont:
2023.
j?n. 12., H, 18:20):
>
>
> On 12/06/2023 16:42, Tam?s N?meth via samba wrote:
> > 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,
> >
> >
>
> Hi Tamas, I did some testing myself over the weekend, trying to find a
> way through this. I knew that a group could also be a user on a Samba DC
> and that if you used the 'rid' idmap backend on a Unix domain
member,
> you got a synthetic user group, that was as far as I thought it went.
>
> Which doesn't explain this on a 'rid' based Unix domain member:
>
> sudo ls -lad /srv/ownertest/
> drwxr-xr-x 2 domain users root 4096 Jun 11 08:31 /srv/ownertest/
>
> Yes, a group can own things on a Unix domain member. I have no idea when
> this happened, but it does match what Windows does and it appears to
> only work with AD groups:
>
> rowland at devstation:~$ sudo mkdir /srv/ownertest2
> rowland at devstation:~$ ls -lad /srv/ownertest2
> drwxr-xr-x 2 root root 4096 Jun 12 16:58 /srv/ownertest2
>
> rowland at devstation:~$ grep 'unixtest' /etc/passwd
> rowland at devstation:~$ grep 'unixtest' /etc/group
> unixtest:x:1001:rowland
>
> rowland at devstation:~$ sudo chown unixtest /srv/ownertest2
> chown: invalid user: ?unixtest?
>
> Which doesn't help you.
>
> I wouldn't use Samba 3.2.5 , it is just too old and will no doubt be
> riddled with things that have been fixed with CVE's, but it is your
choice.
>
> I was hoping that you could use the two parameters I referred to
> earlier, but, from my testing, it is a bit of a chicken & egg
situation.
> You need to be able to read the Unix permissions to create anything, but
> you cannot if the lines are set.
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>