[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 15:16:18 BST 2022
On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen <jwittlincohen at gmail.com>
wrote:
> ---------- 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:
>
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 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:
>
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.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/7376f1a7/attachment-0001.htm>
More information about the Pkg-samba-maint
mailing list