Comment 1 for bug 1962166

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

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.