Uploaded to jammy unapproved:
Uploading samba_4.15.13+dfsg-0ubuntu1.9.dsc
Uploading samba_4.15.13+dfsg-0ubuntu1.9.debian.tar.xz
Uploading samba_4.15.13+dfsg-0ubuntu1.9_source.buildinfo
Uploading samba_4.15.13+dfsg-0ubuntu1.9_source.changes
** Description changed:
[ Impact ]
After upgrading Samba from 2:4.15.13+dfsg-0ubuntu1.5 to
2:4.15.13+dfsg-0ubuntu1.8 (to fix LP: #2120811), the %m variable in the
smb.conf configuration file stopped resolving to the hostname as it
previously did, and now resolves to an IP address.
Note this is the second regression in the original LP: #2116098 SRU,
which changed samba to cope with security changes that landed in Windows
Server. In the first regression (LP: #2120811), the macros were not
being expanded. A no-change rebuild fixed that, so the real cause was
never determined. An autopkgtest was added to check for the %U macro,
and users reported that %m was also "working".
Now we see that %m was no longer empty, but contained an IP instead of a
netbios name. This time a missing patch was identified, and added to the
stack. A new autopkgtest to explicitly check for %m was also added.
[ Test Plan ]
The test plan consists of two parts:
a) passing autopkgtests. Specifically, the test named smbclient-macro-
expansion which was updated to also test %m (it already tests %U, from
the previous SRU). This is the extra check that this test does:
+ echo Checking if connection attempts generated a logfile log.netbios2243
+ ls -l /var/log/samba/log.netbios2243
-rw-r--r-- 1 root root 187 Sep 17 14:27 /var/log/samba/log.netbios2243
In this test run, %m correctly expanded to a name ("netbios2243")
instead of an IP.
b) Repeat the test plan of the original SRU that started all this: LP:
#2116098.
[ Where problems could occur ]
This time we are adding an extra patch that was missed from the original
SRU LP: #2116098. This patch is already included in noble and later
releases of Ubuntu. Regression potential is still in the area of macro
expansions and windows interoperability with the new Windows Server
security checks, addressed by the original SRU. To mitigate these risks,
a new autopkgtest was added specifically for the macro expansion issue,
and the interoperability with Windows Server 2025 is being tested again,
within the scope of the original SRU.
It is still now known how a no-change-rebuild fixed LP: #2120811, but
should that bug manifest itself again, this time we have autopkgtests
covering both %U and %m macros. A question could be raised about all the
other possible macros, but I don't think we are there yet. In LP:
#2120811, ALL macros stopped working, and for %m, we actually identified
a patch that was missing.
[ Other Info ]
- Not at this time. Other than I really hope this is the last regression
- fix we will need.
+ I really hope this is the last regression fix we will need.
+
+ The new dep8 test is not in questing (current ubuntu devel release). I
+ could upload it, but we are in post-beta freeze.
[ Original Description ]
Description:
After upgrading Samba from 2:4.15.13+dfsg-0ubuntu1.5 to
2:4.15.13+dfsg-0ubuntu1.8, the %m variable in the smb.conf configuration
file stopped resolving to the hostname as it previously did. This issue
affects configurations that rely on %m for host-based home directory
mapping.
Use Case:
My Samba server is configured to serve user home directories based on
both hostname and username. Here is the relevant section of my
/etc/samba/smb.conf:
[homes]
comment = Home Directories
path = /share/samba/%m/%S
This configuration had worked for years. For example, when client1
connected as user1, the server would serve the home directory from:
/share/samba/client1/user1
Observed Behavior:
Up to version 2:4.15.13+dfsg-0ubuntu1.6:
%m was correctly substituted with the client's hostname (e.g., client1).
In version 2:4.15.13+dfsg-0ubuntu1.7:
%m was empty (""), causing Samba to try accessing /share/samba//user1,
which failed due to a nonexistent path.
In version 2:4.15.13+dfsg-0ubuntu1.8:
%m is now set to the client's IP address (e.g., 192.168.1.123) instead of
the hostname, resulting in paths like:
/share/samba/192.168.1.123/user1
This is not the intended behavior and breaks existing configurations.
Debugging:
To debug the value of %m, I added the following line to the config:
preexec = /bin/sh -c 'echo m=%m >> /tmp/smb.log'
Results:
With 2:4.15.13+dfsg-0ubuntu1.5 (or .6):
m=client1
With 2:4.15.13+dfsg-0ubuntu1.7:
m=
With 2:4.15.13+dfsg-0ubuntu1.8:
m=192.168.1.123
Conclusion:
This appears to be a regression in how Samba resolves %m. It may be
related to [Bug 2120811], which also affected other variables like %U.
For now, I’ve reverted to 2:4.15.13+dfsg-0ubuntu1.5, where everything
works as expected. I'm hoping for a fix or clarification in a future
release.
Best regards.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2123902
Title:
Regression in %m Variable Substitution: IP instead of name
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2123902/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
