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

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

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

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.

I can reproduce this issue, and will investigate.

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

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

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

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

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

*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...

Yes, definitely. Reopening.

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.

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.

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

Thanks

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.

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.

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.

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