Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull
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 < jwittlinco...@gmail.com> wrote: > > > On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen < > jwittlinco...@gmail.com> wrote: > >> -- Forwarded message -- >> >>> From: Michael Tokarev >>> To: Jason Cohen , 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/5f67d36ff617
Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull
On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen wrote: > -- Forwarded message -- > >> From: Michael Tokarev >> To: Jason Cohen , 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. I
Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull
-- Forwarded message -- > From: Michael Tokarev > To: Jason Cohen , 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/permiss
