** 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.
+ 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 ]
- * detailed instructions how to reproduce the bug
+ The test plan consists of two parts:
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package
- fixes the problem.
+ 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:
- * if other testing is appropriate to perform before landing this
- update, this should also be described here.
+ + 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 ]
* Think about what the upload changes in the software. Imagine the
change is wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the event
of a regression.
* This must never be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Make sure to explain any deviation from the norm, to save the SRU
reviewer from having to infer your reasoning, possibly incorrectly.
This should also help reduce review iterations, particularly when the
reason for the deviation is not obvious.
* Anticipate questions from users, SRU, +1 maintenance, security teams
and the Technical Board and address these questions in advance
[ 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.
** 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
+ + 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 ]
- * Think about what the upload changes in the software. Imagine the
- change is wrong or breaks something else: how would this show up?
+ 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 assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the event
- of a regression.
-
- * This must never be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
-
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the 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 ]
- * Anything else you think is useful to include
-
- * Make sure to explain any deviation from the norm, to save the SRU
- reviewer from having to infer your reasoning, possibly incorrectly.
- This should also help reduce review iterations, particularly when the
- reason for the deviation is not obvious.
-
- * Anticipate questions from users, SRU, +1 maintenance, security teams
- and the Technical Board and address these questions in advance
+ Not at this time. Other than I really hope this is the last regression
+ fix we will need.
[ 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
