<div dir="ltr"><div class="gmail_quote"><div>---------- Forwarded message ----------</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From: Michael Tokarev <<a href="mailto:mjt@tls.msk.ru" target="_blank">mjt@tls.msk.ru</a>><br>To: Jason Cohen <<a href="mailto:jasonwc.server@gmail.com" target="_blank">jasonwc.server@gmail.com</a>>, <a href="mailto:1019545-done@bugs.debian.org" target="_blank">1019545-done@bugs.debian.org</a><br>Cc: <br>Bcc: <br>Date: Thu, 15 Sep 2022 13:17:28 +0300<br>Subject: Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye<br>11.09.2022 19:28, Jason Cohen wrote:<br>
> Package: samba<br>
> Version: 2:4.16.4+dfsg-2~bpo11+1<br>
> Severity: normal<br>
> <br>
> Dear Maintainer,<br>
> <br>
> *** Reporter, please consider answering these questions, where appropriate ***<br>
> <br>
> * What led up to the situation?<br>
> <br>
> 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.<br>
<br>
Just to clarify: 4.16[.4] is not part of bullseye, but is available in bullseye-backports.<br>
It's okay, it is just that from your statement one might conclude that upgrade to bullseye<br>
caused samba to be updated to 4.16.4, - no, it is not, you explicitly installed samba from<br>
backports.<br>
<br>
Also note that across-release upgrades has never been supported in debian. You can upgrade<br>
from buster version to bullseye version and only after that you can upgrade to bookworm<br>
version (which is what the bullseye-backport essentially is), but not from buster directly<br>
to bookworm.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>Start-Date: 2022-08-31 22:50:37<br>Commandline: apt install -t bullseye-backports samba<br>Requested-By: jason (1000)<br>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)<br>End-Date: 2022-08-31 22:52:40<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Tho, I don't think this matters here, - it is just a side note.<br>
<br>
> * What exactly did you do (or not do) that was effective (or<br>
> ineffective)?<br>
> <br>
> 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."<br>
> <br>
> 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.<br>
<br>
That's lovely. It is definitely a bug that samba *crashes* when usershare dir is not accessible.<br>
<br>
But I don't know if this is actually a bug in the behavior change as you describe. It seems to<br>
be, but the thing is that usershare permission model always worked like this. At least as far<br>
as I know.<br>
<br>
In 4.16 I changed the way how usershare directory is handled during install indeed, with this<br>
commit:<br>
<br>
<a href="https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5" rel="noreferrer" target="_blank">https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5</a><br>
<br>
This means I only create this dir and specify its permissions only at first install, not every<br>
install. But again, this is not really relevant.<br>
<br>
Now, I don't know which permissions/ownership you files *had* before you changed them. Please<br>
note how this directory is being created:<br>
<br>
install -d -m 1770 -g sambashare /var/lib/samba/usershares<br>
<br>
The "1" "sticky" bit tells the kernel to use the same group for all subdirectories and files<br>
created within. So you should not need to change the group ownership in the first place. If<br>
you had to, it means this sticky bit hasn't been there in your case. Which, in turn, means<br>
some local modification you did, probably.<br>
<br>
Either way, after you actually changed the ownership/permission bits, it's impossible to<br>
see what the actual problem was.<br>
<br>
Due to this, I'm closing this bugreport, since there's no data in there to work with.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>I chose a snapshot from August 22nd as that was well before I touched any permissions or ownership in /var/lib/samba. </div><div><br></div><div>8/22/22 var/lib/sambashare:</div><div><br></div><div>-rw-r--r-- 1 root root 95 Jun 11 2021 data<br></div><div><br></div><div>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. </div><div><br></div><div>These shares are created by the following zfs dataset property:</div><div><br></div><div>jason@storage-server:~$ zfs get sharesmb data<br>NAME PROPERTY VALUE SOURCE<br>data sharesmb on local<br></div><div><br></div><div>The shares listed in smb.conf had correct permissions. For example:</div><div><br></div><div>-rw-r--r-- 1 root sambashare 137 Mar 28 2015 backups1_documents<br></div><div><br></div><div>9/15/22 var/lib/sambashare:</div><div><br></div><div>-rw-r--r-- 1 root sambashare 95 Jun 11 2021 data<br></div><div><br></div><div>So, I changed ownership from root:root to root:sambashare. Permissions look identical. </div><div><br></div><div>The other difference is that my user, jason, was not added to the sambashare group as of the 8/22/22 snapshot:</div><div><br></div><div>8/22/22 /etc/groups:</div><div>sambashare:x:121:<br></div><div><br></div><div>9/15/22 /etc/groups:</div><div>sambashare:x:121:jason<br></div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
/mjt<br><br><br>---------- Forwarded message ----------<br>From: Jason Cohen <<a href="mailto:jasonwc.server@gmail.com" target="_blank">jasonwc.server@gmail.com</a>><br>To: Debian Bug Tracking System <<a href="mailto:submit@bugs.debian.org" target="_blank">submit@bugs.debian.org</a>><br>Cc: <br>Bcc: <br>Date: Sun, 11 Sep 2022 12:28:23 -0400<br>Subject: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye<br>Package: samba<br>
Version: 2:4.16.4+dfsg-2~bpo11+1<br>
Severity: normal<br>
<br>
Dear Maintainer,<br>
<br>
*** Reporter, please consider answering these questions, where appropriate ***<br>
<br>
* What led up to the situation?<br>
<br>
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.<br>
<br>
* What exactly did you do (or not do) that was effective (or<br>
ineffective)?<br>
<br>
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." <br>
<br>
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.<br>
<br>
* What was the outcome of this action?<br>
<br>
Changing the ownership to root:sambashare and adding my user to the sambashare group resolved the segfaults. <br>
<br>
* What outcome did you expect instead?<br>
<br>
<br>
-- Package-specific info:<br>
* /etc/samba/smb.conf present, and attached<br>
* /var/lib/samba/dhcp.conf present, and attached<br>
<br>
-- System Information:<br>
Debian Release: 11.5<br>
APT prefers stable-updates<br>
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')<br>
Architecture: amd64 (x86_64)<br>
<br>
Kernel: Linux 5.10.0-17-amd64 (SMP w/32 CPU threads)<br>
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE<br>
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<br>
Shell: /bin/sh linked to /bin/dash<br>
Init: systemd (via /run/systemd/system)<br>
LSM: AppArmor: enabled<br>
<br>
Versions of packages samba depends on:<br>
ii adduser 3.118<br>
ii init-system-helpers 1.60<br>
ii libbsd0 0.11.3-1<br>
ii libc6 2.31-13+deb11u4<br>
ii libcups2 2.3.3op2-3+deb11u2<br>
ii libgnutls30 3.7.1-5+deb11u2<br>
ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1<br>
ii libldb2 2:2.5.2+samba4.16.4-2~bpo11+1<br>
ii libpam-modules 1.4.0-9+deb11u1<br>
ii libpam-runtime 1.4.0-9+deb11u1<br>
ii libpopt0 1.18-2<br>
ii libtalloc2 2.3.3-4~bpo11+1<br>
ii libtasn1-6 4.16.0-2<br>
ii libtdb1 1.4.6-3~bpo11+1<br>
ii libtevent0 0.11.0-1~bpo11+1<br>
ii lsb-base 11.1.0<br>
ii procps 2:3.3.17-5<br>
ii python3 3.9.2-3<br>
ii python3-dnspython 2.0.0-1<br>
ii python3-samba 2:4.16.4+dfsg-2~bpo11+1<br>
ii samba-common 2:4.16.4+dfsg-2~bpo11+1<br>
ii samba-common-bin 2:4.16.4+dfsg-2~bpo11+1<br>
ii samba-libs 2:4.16.4+dfsg-2~bpo11+1<br>
ii tdb-tools 1.4.3-1+b1<br>
<br>
Versions of packages samba recommends:<br>
ii attr 1:2.4.48-6<br>
ii logrotate 3.18.0-2+deb11u1<br>
ii python3-markdown 3.3.4-1<br>
ii samba-dsdb-modules 2:4.16.4+dfsg-2~bpo11+1<br>
ii samba-vfs-modules 2:4.16.4+dfsg-2~bpo11+1<br>
<br>
Versions of packages samba suggests:<br>
ii bind9 1:9.16.27-1~deb11u1<br>
ii bind9-utils [bind9utils] 1:9.16.27-1~deb11u1<br>
ii bind9utils 1:9.16.27-1~deb11u1<br>
ii ctdb 2:4.16.4+dfsg-2~bpo11+1<br>
pn ldb-tools <none><br>
ii ntp 1:4.2.8p15+dfsg-1<br>
pn smbldap-tools <none><br>
pn ufw <none><br>
pn winbind <none><br>
<br>
-- Configuration Files:<br>
/etc/logrotate.d/samba changed:<br>
/var/log/samba/log.smbd {<br>
weekly<br>
missingok<br>
rotate 7<br>
postrotate<br>
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid ] || /usr/bin/smbcontrol smbd reload-config<br>
endscript<br>
#compress<br>
delaycompress<br>
notifempty<br>
}<br>
/var/log/samba/log.nmbd {<br>
weekly<br>
missingok<br>
rotate 7<br>
postrotate<br>
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config<br>
endscript<br>
#compress<br>
delaycompress<br>
notifempty<br>
}<br>
/var/log/samba/log.samba {<br>
weekly<br>
missingok<br>
rotate 7<br>
postrotate<br>
if [ -d /run/systemd/system ] && command systemctl >/dev/null 2>&1 && systemctl is-active --quiet samba-ad-dc; then<br>
systemctl kill --kill-who all --signal=SIGHUP samba-ad-dc<br>
elif [ -f /run/samba/samba.pid ]; then<br>
# This only sends to main pid, See #803924<br>
kill -HUP `cat /run/samba/samba.pid`<br>
fi<br>
endscript<br>
#compress<br>
delaycompress<br>
notifempty<br>
}<br>
<br>
<br>
-- debconf information:<br>
samba/run_mode: daemons<br>
samba-common/title:<br>
</blockquote></div></div>