DEP8 failing with samba 4.15.5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
backuppc |
New
|
Unknown
|
|||
samba |
Unknown
|
Unknown
|
|||
backuppc (Ubuntu) |
Fix Released
|
Undecided
|
Sergio Durigan Junior | ||
samba (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
With samba 4.15.5, currently in jammy proposed, the smb backup test is showing multiple failures[1]:
XferErr cmdExecOrEval: about to exec /usr/bin/smbclient \\\\localhost\
tarExtract: /usr/share/
tarExtract: /usr/share/
tarExtract: ^@^@^@^
__bpc_progress_
new 0 0/0 0 ^@^@^@^
tarExtract:
...
tarExtract: 8190: checksum error at
tarExtract: Got unknown type 8 for 81887
tarExtract: 81888
...
tarExtract: Done: 8918 errors, 3659 filesExist, 1182600 sizeExist, 360882 sizeExistComp, 3980 filesTotal, 1593860 sizeTotal, 321 filesNew, 411260 sizeNew, 40098 sizeNewComp, 2499 inodeLast
With samba 4.13 the test works.
Related branches
- Lucas Kanashiro (community): Approve
- Canonical Server packageset reviewers: Pending requested
-
Diff: 324 lines (+186/-65)6 files modifieddebian/changelog (+34/-0)
debian/control (+2/-1)
debian/tests/authenticated-smb-backup (+54/-0)
debian/tests/common (+78/-0)
debian/tests/control (+1/-1)
debian/tests/smb-backup (+17/-63)
- Canonical Server packageset reviewers: Pending requested
- Canonical Server: Pending requested
-
Diff: 88 lines (+46/-5) (has conflicts)3 files modifieddebian/changelog (+35/-0)
debian/copyright (+11/-1)
debian/rules (+0/-4)
- Andreas Hasenack: Approve
- Canonical Server packageset reviewers: Pending requested
- Canonical Server: Pending requested
-
Diff: 45 lines (+12/-3)3 files modifieddebian/changelog (+8/-0)
debian/control (+2/-1)
debian/tests/smb-backup (+2/-2)
Changed in backuppc (Ubuntu): | |
status: | New → Triaged |
tags: | added: update-excuse update-excuses |
Changed in samba (Ubuntu): | |
status: | New → Triaged |
Changed in backuppc (Ubuntu): | |
assignee: | Andreas Hasenack (ahasenack) → Sergio Durigan Junior (sergiodj) |
Changed in backuppc: | |
status: | Unknown → New |
I investigated this bug and found that it's possibly a regression introduced in the 4.15.x series of Samba.
In a nutshell, Samba offers guest authentications (i.e., when username/password are provided but are ignored by libsmbclient, which will map the request to the Guest user configured on smb.conf), and anonymous authentication (i.e., when the username/password are empty; this is equivalent to invoking smbclient with -N).
I found that, on Samba 4.13.14 (currently in the -release pocket on Jammy), it is possible to perform an anonymous authentication using an empty password (specific via the PASSWD environment variable) and an empty user (specified via smbclient's -U option, but without actually providing a user). However, on Samba 4.15.5 (curent in the -proposed pocket on Jammy), this exact scenario doesn't work anymore.
backuppc will invoke smbclient exactly as described above, and that's what's triggering the problem. But it's possible to reproduce the problem without backuppc:
$ lxc launch ubuntu-daily:jammy samba-bug1962166
$ lxc shell samba-bug1962166
# apt update && apt full-upgrade -y
# apt install samba smbclient -y
# cat >> /etc/samba/smb.conf << EOF
[test]
path = /srv/test
read only = yes
guest ok = yes
browseable = yes
EOF
# mkdir /srv/test
# systemctl reload smbd.service
# PASSWD="" smbclient \\\\localhost\\test -U -L
Try "help" to get a list of possible commands.
smb: \>
Now, enable the -proposed repository inside the container, update samba and run the same command again. You will see:
# PASSWD="" smbclient \\\\localhost\\test -U -L
Password for [WORKGROUP\-L]:
smbclient doesn't recognize the empty user anymore; instead, it assumes that the username is "-L", which is obviously wrong.
Arguably, this method of authentication is very fragile (it relies on an obscure way to parse the command line arguments and identify that "-U" without a valid username in front of it actually means an empty user) and it could be said that it is backuppc's responsibility to identify when the samba share's user/password are empty and invoke smbclient with -N. However, it is not entirely clear to me whether this was an intentional change of behaviour or not, so I went ahead and filed an upstream bug explaining the situation to them. Hopefully we will get more pointers.
Meanwhile, I have a simple workaround that makes backuppc's autopkgtest pass again. Basically, we just need to actually provide a non-empty username/password combination when authenticating (it doesn't need to be valid data; anything will do); smbclient will then fall back to the guest authentication explained above. I will file an MP soon.