[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:47:02 BST 2022
One more factor that may be relevant. This is a really old Debian install.
It was first installed sometime in 2014 and thus would have used Wheezy .
So, it's been upgraded from Wheezy > Jessie > Stretch > Buster > Bullseye.
/var/lib/samba/usershares contains files dated from January 2015 through
September 13, 2022
-rw-r--r-- 1 root sambashare 104 Jan 17 2015 backups
On Thu, Sep 15, 2022 at 10:16 AM Jason Wittlin-Cohen <
jwittlincohen at gmail.com> wrote:
>
>
> 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/5c52525a/attachment-0001.htm>
More information about the Pkg-samba-maint
mailing list