[Pkg-samba-maint] Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye

[Michael Tokarev]

15.09.2022 16:58, Jason Wittlin-Cohen wrote:
[]
> I chose a snapshot from August 22nd as that was well before I touched any permissions or ownership in /var/lib/samba.
> 
> 8/22/22 var/lib/sambashare:
> 
> -rw-r--r-- 1 root root        95 Jun 11  2021 data
> 
> So, the user and group ownership is root. "data" was the share causing me problems, and it's the primary share that I access from my Windows systems. 
> I think I know why the permissions were wrong. This share, as well as several others, are created by ZFS.  They are not listed in smb.conf.
> 
> These shares are created by the following zfs dataset property:
> 
> jason at storage-server:~$ zfs get sharesmb data
> NAME  PROPERTY  VALUE     SOURCE
> data  sharesmb  on        local
> 
> The shares listed in smb.conf had correct permissions.  For example:
> 
> -rw-r--r-- 1 root sambashare 137 Mar 28  2015 backups1_documents
> 
> 9/15/22 var/lib/sambashare:
> 
> -rw-r--r-- 1 root sambashare  95 Jun 11  2021 data
> 
> So, I changed ownership from root:root to root:sambashare. Permissions look identical.

This changed nothing. The "data" file can be read by anyone, since
it has identical read permissions for group and for others, so it
doesn't matter which group it is.  Unless ZFS adds its own semantics
for standard Unix rwx model.  With regular filesystem it would have
worked exactly the same either way.

I might be a good idea to capture an strace output of smbd process
when it reported the permission problem.

> The other difference is that my user, jason, was not added to the sambashare group as of the 8/22/22 snapshot:
> 
> 8/22/22 /etc/groups:
> sambashare:x:121:
> 
> 9/15/22 /etc/groups:
> sambashare:x:121:jason

This, as I mentioned before, is only relevant for *adding* new user shares,
but not for accessing already existing shares. Members of sambashare group
are able to *add* new entries (regular files describing share definitions)
to this directory.

> I hope this helps. It appears the behavior I saw was due to the root:root ownership used by ZFS to create shares.  For whatever reason, this worked in 
> Buster but caused the crashes once I upgraded to the stable-sec or bullseye-backports versions in Bullseye.

I tried various combinations of permissions here locally, - I can't
reproduce the crashes, but I do see the warning about being unable to
access files within this usershares/ dir in some cases (which are normal
and harmless).

But I don't use and don't have ZFS.

/mjt