Samba user home path not accessible if directory added after %U - canonicalize_connect_path failed

[Richard Leger]

Hi,

In our Samba 4.13.17 configuration file, we have defined the user home path as below:
path = /home/%U/FILES

It worked find up to Ubuntu 20.04 with package version Samba version 2:4.13.17~dfsg-0ubuntu1.20.04.2

But since update to Samba version 2:4.13.17~dfsg-0ubuntu1.20.04.4, it does no longer works with error message: canonicalize_connect_path failed, preventing end-user accessing their home drive.

Jan 25 11:17:52 ff0119 smbd[2657856]: [2023/01/25 11:17:52.605790, 0] ../../source3/smbd/service.c:785(make_connection_snum)
Jan 25 11:17:52 ff0119 smbd[2657856]: make_connection_snum: canonicalize_connect_path failed for service john, path /home/FILES

Indeed in the logs, instead of trying to access /home/john/FILES for user john, Samba seems to be trying to access /home/FILES (the user part of the path being stripped out for some unknown reason). It is like the %U value become empty or unreadable.

Other paths such as logon script do not seem affected by the issue. The other shared folders remain fully accessible to end-user but not their home directory.

For now the only workaround we may have found working is either:
- to use a different home path without sub-folder: /home/%U in the samba configuration
- downgrade Samba to package version 2:4.13.17~dfsg-0ubuntu1.20.04.2
- setup manually a new share with the full manual path of the user home directory (/home/john/FILES) without using the %U then access to the directory works... not the most convenient in a large multi-user environment..

In help you could provide in resolving this issue quickly would be much appreciated.

Regards,
Richard

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Richard Leger (richard-leger)]

FYI,

We've tested on Ubuntu 18.04 servers and they do *not* have the problem. Package version is:
    2:4.7.6+dfsg~ubuntu-0ubuntu2.29

On one of our Ubuntu 22.04 test machines, the update version works fine:
    2:4.15.13+dfsg-0ubuntu1

[zaqmzcvnvn5sm5gmt (zaqmzcvnvn5sm5gmt)]

Same version, same / similar problem:

"path = /home/%U" is interpreted as "path = /home/"

Workaround: Use a lower case "u":

"path = /home/%u"

Our users were complaining, that they could see all other users home directories, so this bug also has security implications. "path = /foo/%u/bar" is working too - I just hope using lowercase u has no side effects.

[Marc Deslauriers (mdeslaur)]

I can reproduce this issue, and will investigate.

[Marc Deslauriers (mdeslaur)]

I will be releasing an update later today with the security fixes reverted until we track down the regression.

[Adam Thorn (alt36)]

https://bugzilla.samba.org/show_bug.cgi?id=15243 has been suggested as the issue and fix on the samba mailing list.

[Launchpad Janitor (janitor)]

This bug was fixed in the package samba - 2:4.13.17~dfsg-0ubuntu1.20.04.5

---------------
samba (2:4.13.17~dfsg-0ubuntu1.20.04.5) focal-security; urgency=medium

  * SECURITY UPDATE: Multiple regressions (LP: #2003867) (LP: #2003891)
    - debian/patches/series: disable all security fixes from the previous
      update pending further investigation. This reverts the following
      CVEs: CVE-2022-3437, CVE-2022-42898, CVE-2022-45141, CVE-2022-38023,
      CVE-2022-37966, CVE-2022-37967.

 -- Marc Deslauriers <email address hidden> Thu, 26 Jan 2023 09:03:40 -0500

[Marc Deslauriers (mdeslaur)]

I have reverted the update for now, but am reopening this bug so we can fix the regression and publish a new update soon.

[Launchpad Janitor (janitor)]

This bug was fixed in the package samba - 2:4.13.17~dfsg-0ubuntu1.20.04.5

---------------
samba (2:4.13.17~dfsg-0ubuntu1.20.04.5) focal-security; urgency=medium

  * SECURITY UPDATE: Multiple regressions (LP: #2003867) (LP: #2003891)
    - debian/patches/series: disable all security fixes from the previous
      update pending further investigation. This reverts the following
      CVEs: CVE-2022-3437, CVE-2022-42898, CVE-2022-45141, CVE-2022-38023,
      CVE-2022-37966, CVE-2022-37967.

 -- Marc Deslauriers <email address hidden> Thu, 26 Jan 2023 09:03:40 -0500

[John Runyon (dimecadmiu)]

*bump* this (or 2003867) should probably be re-opened again since the security updates still need to be fixed and re-applied at some point...

[Marc Deslauriers (mdeslaur)]

Yes, definitely. Reopening.

[Marc Deslauriers (mdeslaur)]

The following update that was published today should fix the security issues without reintroducing this bug:

https://ubuntu.com/security/notices/USN-5936-1

I am closing this bug, if the issue persists with the new version, please don't hesitate to reopen it again.

[Jakob Mortensen (ubjmortensen)]

After installing the above fix (2:4.15.13+dfsg-0ubuntu0.20.04.2) yesterday (12/4 2023) we end up with reintroducing the problem that users cannot access their home drives.

[Seth Arnold (seth-arnold)]

Hello Jakob, are there any errors in the samba logs or journalctl from launching or attempting to access the shares?

Thanks

[Jakob Mortensen (ubjmortensen)]

Thank you for your reply. We had to roll back our file-server and were stupid enough not to get the log files out. But when we did a "systemctl status smbd.service" it said that permission to the "homes-directory" (and other shared folders) was denied and the path it wrote to the "homes-direcotry" (and other shared folders) was wrong. That was exactly the same we experienced last time. Everything worked again after we rolled back our file-server.

[Jakob Mortensen (ubjmortensen)]

We tried installing the update again, and it failed again. The drives can't be accessed from the clients.
We went from version 2:4.15.13+dfsg-0ubuntu0.20.04.1 to version 2:4.15.13+dfsg-0ubuntu0.20.04.2
Here is the content from the log.smbd file:
... smbd[14752]: [2023/04/20 09:12:48.096781, 0] ../../source3/param/loadparm.c:3448(process_usershare_file)
... smbd[14752]: process_usershare_file: stat of /var/lib/samba/usershares/homes failed. Permission denied
The problem is that /var/lib/samba/usershares/homes doesn't exist. This path is not anywhere in the conf files. So why does samba look here?
The path to the homes-share in the relevant conf file is path = /home/data/%S and that hasn't changed for years.
Any help would be greately appriciated.

[Jakob Mortensen (ubjmortensen)]

Just to add some more: We have made a test-setup where we update everything else except samba, checks that everything works and then update samba from 2:4.15.13+dfsg-0ubuntu0.20.04.1 to version 2:4.15.13+dfsg-0ubuntu0.20.04.2 and everything breaks down.
The we increased the log level.
In the test-setup there is a windows-server called RD2019. So we have a conf file called rd2019.conf under /etc/samba. In smb.conf we have an include statement saying: include = /etc/samba/%m.conf.
Now in log.smbd it says that it can't find /etc/samba/"ip-address of RD2019".conf. So it has stopped looking for the file name rd2019.conf after the update. So somehow it doesn't understand the %m parameter in the include statement after the update. Network, dns etc. is all the same before and after the update, so only samba has changed. If we rename the conf file to RD2019.conf the error stays. If we rename the conf file to "ip-address of RD2019".conf network-shares are mapped correctly and everything works! Is there another parameter than %m that we should use or is this a bug?
Any help would be very, very much appreciated.

[Richard Leger (richard-leger)]

This bug is back on the burner, see bug #2039031 for more details.