[Pkg-samba-maint] Bug#1019545: closed by Michael Tokarev <mjt at tls.msk.ru> (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye)
Jason Wittlin-Cohen
jwittlincohen at gmail.com
Thu Sep 15 14:58:44 BST 2022
---------- Forwarded message ----------
> From: Michael Tokarev <mjt at tls.msk.ru>
> To: Jason Cohen <jasonwc.server at gmail.com>, 1019545-done at bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 15 Sep 2022 13:17:28 +0300
> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
> /var/lib/samba results in repeated panic or segfault after upgrading from
> Buster to Bullseye
> 11.09.2022 19:28, Jason Cohen wrote:
> > Package: samba
> > Version: 2:4.16.4+dfsg-2~bpo11+1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> > * What led up to the situation?
> >
> > I upgraded my system from Buster to Bullseye. As part of that process,
> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
> reporting a Panic or segfault in Samba everytime a user tried to access a
> file share after going idle.
>
> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
> bullseye-backports.
> It's okay, it is just that from your statement one might conclude that
> upgrade to bullseye
> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
> installed samba from
> backports.
>
> Also note that across-release upgrades has never been supported in debian.
> You can upgrade
> from buster version to bullseye version and only after that you can
> upgrade to bookworm
> version (which is what the bullseye-backport essentially is), but not from
> buster directly
> to bookworm.
>
Yes, that's correct. When I upgraded from Buster to Bullseye, the version
in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5). I manually
installed the bullseye-backports version to see if it would rectify the
issue, but it didn't.
Start-Date: 2022-08-31 22:50:37
Commandline: apt install -t bullseye-backports samba
Requested-By: jason (1000)
Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1)
End-Date: 2022-08-31 22:52:40
>
> Tho, I don't think this matters here, - it is just a side note.
>
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> >
> > After enabling debug logging, I saw that the panic/segfault was
> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
> failed. Permission denied."
> >
> > In order to fix the issue, I changed the file ownership of all files in
> the above directory to root:sambashare and added my user (jason) to the
> sambashare group. After making these changes, the errors went away. I am
> reporting this as it's a change in behavior. I did not experience these
> segfaults in Buster. It appears that the expected ownership of this
> directory changed, causing my issue.
>
> That's lovely. It is definitely a bug that samba *crashes* when usershare
> dir is not accessible.
>
> But I don't know if this is actually a bug in the behavior change as you
> describe. It seems to
> be, but the thing is that usershare permission model always worked like
> this. At least as far
> as I know.
>
> In 4.16 I changed the way how usershare directory is handled during
> install indeed, with this
> commit:
>
>
> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5
>
> This means I only create this dir and specify its permissions only at
> first install, not every
> install. But again, this is not really relevant.
>
> Now, I don't know which permissions/ownership you files *had* before you
> changed them. Please
> note how this directory is being created:
>
> install -d -m 1770 -g sambashare /var/lib/samba/usershares
>
> The "1" "sticky" bit tells the kernel to use the same group for all
> subdirectories and files
> created within. So you should not need to change the group ownership in
> the first place. If
> you had to, it means this sticky bit hasn't been there in your case.
> Which, in turn, means
> some local modification you did, probably.
>
> Either way, after you actually changed the ownership/permission bits, it's
> impossible to
> see what the actual problem was.
>
> Due to this, I'm closing this bugreport, since there's no data in there to
> work with.
>
I apologize for not including this pertinent information. My root
filesystem uses ZFS, and I maintain daily snapshots for at least 30 days.
As I discovered I discovered the cause of the Samba crashes on September
1st per my IRC logs, i was able to check the ZFS snapshots for a prior
date. A ZFS snapshot is simply a read-only filesystem as of the time it
was created . As such, I can see the contents of any file on the file
system as well as their permissions and ownership.
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.
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
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.
>
> Thanks,
>
> /mjt
>
>
> ---------- Forwarded message ----------
> From: Jason Cohen <jasonwc.server at gmail.com>
> To: Debian Bug Tracking System <submit at bugs.debian.org>
> Cc:
> Bcc:
> Date: Sun, 11 Sep 2022 12:28:23 -0400
> Subject: samba: Permission/ownership issue in /var/lib/samba results in
> repeated panic or segfault after upgrading from Buster to Bullseye
> Package: samba
> Version: 2:4.16.4+dfsg-2~bpo11+1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
> * What led up to the situation?
>
> I upgraded my system from Buster to Bullseye. As part of that process,
> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
> reporting a Panic or segfault in Samba everytime a user tried to access a
> file share after going idle.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> After enabling debug logging, I saw that the panic/segfault was preceeded
> by the following error:L "stat of /var/lib/samba/usershare/data failed.
> Permission denied."
>
> In order to fix the issue, I changed the file ownership of all files in
> the above directory to root:sambashare and added my user (jason) to the
> sambashare group. After making these changes, the errors went away. I am
> reporting this as it's a change in behavior. I did not experience these
> segfaults in Buster. It appears that the expected ownership of this
> directory changed, causing my issue.
>
> * What was the outcome of this action?
>
> Changing the ownership to root:sambashare and adding my user to the
> sambashare group resolved the segfaults.
>
> * What outcome did you expect instead?
>
>
> -- Package-specific info:
> * /etc/samba/smb.conf present, and attached
> * /var/lib/samba/dhcp.conf present, and attached
>
> -- System Information:
> Debian Release: 11.5
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-17-amd64 (SMP w/32 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages samba depends on:
> ii adduser 3.118
> ii init-system-helpers 1.60
> ii libbsd0 0.11.3-1
> ii libc6 2.31-13+deb11u4
> ii libcups2 2.3.3op2-3+deb11u2
> ii libgnutls30 3.7.1-5+deb11u2
> ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1
> ii libldb2 2:2.5.2+samba4.16.4-2~bpo11+1
> ii libpam-modules 1.4.0-9+deb11u1
> ii libpam-runtime 1.4.0-9+deb11u1
> ii libpopt0 1.18-2
> ii libtalloc2 2.3.3-4~bpo11+1
> ii libtasn1-6 4.16.0-2
> ii libtdb1 1.4.6-3~bpo11+1
> ii libtevent0 0.11.0-1~bpo11+1
> ii lsb-base 11.1.0
> ii procps 2:3.3.17-5
> ii python3 3.9.2-3
> ii python3-dnspython 2.0.0-1
> ii python3-samba 2:4.16.4+dfsg-2~bpo11+1
> ii samba-common 2:4.16.4+dfsg-2~bpo11+1
> ii samba-common-bin 2:4.16.4+dfsg-2~bpo11+1
> ii samba-libs 2:4.16.4+dfsg-2~bpo11+1
> ii tdb-tools 1.4.3-1+b1
>
> Versions of packages samba recommends:
> ii attr 1:2.4.48-6
> ii logrotate 3.18.0-2+deb11u1
> ii python3-markdown 3.3.4-1
> ii samba-dsdb-modules 2:4.16.4+dfsg-2~bpo11+1
> ii samba-vfs-modules 2:4.16.4+dfsg-2~bpo11+1
>
> Versions of packages samba suggests:
> ii bind9 1:9.16.27-1~deb11u1
> ii bind9-utils [bind9utils] 1:9.16.27-1~deb11u1
> ii bind9utils 1:9.16.27-1~deb11u1
> ii ctdb 2:4.16.4+dfsg-2~bpo11+1
> pn ldb-tools <none>
> ii ntp 1:4.2.8p15+dfsg-1
> pn smbldap-tools <none>
> pn ufw <none>
> pn winbind <none>
>
> -- Configuration Files:
> /etc/logrotate.d/samba changed:
> /var/log/samba/log.smbd {
> weekly
> missingok
> rotate 7
> postrotate
> [ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid
> ] || /usr/bin/smbcontrol smbd reload-config
> endscript
> #compress
> delaycompress
> notifempty
> }
> /var/log/samba/log.nmbd {
> weekly
> missingok
> rotate 7
> postrotate
> [ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid
> ] || /usr/bin/smbcontrol nmbd reload-config
> endscript
> #compress
> delaycompress
> notifempty
> }
> /var/log/samba/log.samba {
> weekly
> missingok
> rotate 7
> postrotate
> if [ -d /run/systemd/system ] && command systemctl
> >/dev/null 2>&1 && systemctl is-active --quiet samba-ad-dc; then
> systemctl kill --kill-who all --signal=SIGHUP
> samba-ad-dc
> elif [ -f /run/samba/samba.pid ]; then
> # This only sends to main pid, See #803924
> kill -HUP `cat /run/samba/samba.pid`
> fi
> endscript
> #compress
> delaycompress
> notifempty
> }
>
>
> -- debconf information:
> samba/run_mode: daemons
> samba-common/title:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-samba-maint/attachments/20220915/6043fda9/attachment-0001.htm>
More information about the Pkg-samba-maint
mailing list