On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen <jwittlinco...@gmail.com> wrote:
> ---------- Forwarded message ---------- > >> From: Michael Tokarev <m...@tls.msk.ru> >> To: Jason Cohen <jasonwc.ser...@gmail.com>, 1019545-d...@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: > Sorry, this should be; /var/lib/samba/usershares/ > > -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@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: > This should read: /var/lib/samba/usershares/ > > -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.ser...@gmail.com> >> To: Debian Bug Tracking System <sub...@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: >> >