Bugzilla – Bug 1222564
writing nsswitch via yast Nsswitch.rb client module can corrupt /etc/nsswitch.conf
Last modified: 2024-04-11 08:10:19 UTC
Created attachment 874164 [details] test script to demonstrate problem yast samba-client updates nsswitch.conf via /usr/share/YaST2/modules/Nsswitch.rb & /usr/share/YaST2/lib/cfa/nsswitch.rb modules which on a tumbleweed system results in a broken system (needing to be booted in rescue/single user mode) this isn't related to samba-client (although I guess it is possible that /usr/share/YaST2/modules/SambaWinbind.pm is using the nsswitch modules incorrectly) I will attach a small example .rb script to show what is happening ensure /etc/nsswitch.conf has a group entry like below (which is what I see for default tw install) group: compat [SUCCESS=merge] systemd run test script /usr/lib/YaST2/bin/y2start test_nsswitch.rb qt after running the script /etc/nsswitch.conf contents for group entry now look like group: [SUCCESS=merge] compat systemd winbind and groups are broken, tw system hangs on boot and never gets to greeter (many systemd processes fail) recovery is possibly with rescue more or single mode boot and manual repair of nssswitch.conf
seems the optional action column is not handled correctly when writing back the entries
So, if someone can explain why this is deemed to be a samba issue we will gladly (maybe gladly is too strong a word :-)) take the bug. But just blanket switching to the samba component isn't really useful Sofar I don't see anything here to do with samba other than samba is using the nsswitch code to modify the config file. (note the nsswitch code is part of yast2-pam (which I don't believe is maintained by the samba team) I did mention in comment #0 "I guess it is possible that /usr/share/YaST2/modules/SambaWinbind.pm is using the nsswitch modules incorrectly" and if that is the case then please tell us and point us at the correct way
rpm -qf /usr/share/YaST2/modules/Nsswitch.rb yast2-pam-5.0.0-lp155.3.1.noarch https://github.com/yast/yast-pam/blob/master/src/modules/Nsswitch.rb https://github.com/yast/yast-pam/blob/master/src/lib/cfa/nsswitch.rb In both files, the ast real code change (the most recent one was just silencing rubocop) was 4 years ago: https://github.com/yast/yast-pam/pull/22 So, are you saying that this never worked correctly? Or is this a recent problem?
(In reply to Stefan Hundhammer from comment #3) > rpm -qf /usr/share/YaST2/modules/Nsswitch.rb > yast2-pam-5.0.0-lp155.3.1.noarch > > > https://github.com/yast/yast-pam/blob/master/src/modules/Nsswitch.rb > https://github.com/yast/yast-pam/blob/master/src/lib/cfa/nsswitch.rb > > In both files, the ast real code change (the most recent one was just > silencing rubocop) was 4 years ago: > > https://github.com/yast/yast-pam/pull/22 > > > So, are you saying that this never worked correctly? > Or is this a recent problem? this is a recent problem since nssswitch.conf (in the most recent tw installs) seems to be using the optional action column please see comment #0 for details and a test script to demonstrate the problem "ensure /etc/nsswitch.conf has a group entry like below (which is what I see for default tw install) group: compat [SUCCESS=merge] systemd run test script /usr/lib/YaST2/bin/y2start test_nsswitch.rb qt after running the script /etc/nsswitch.conf contents for group entry now look like group: [SUCCESS=merge] compat systemd winbind and groups are broken, tw system hangs on boot and never gets to greeter (many systemd processes fail) recovery is possibly with rescue more or single mode boot and manual repair of nssswitch.conf"
then entry after modification should look like group: compat [SUCCESS=merge] systemd winbind the action column '[SUCCESS=merge]' is optional and pertains to the previous (compat) column
Josef, can cfa/nsswitch.rb handle that format? Or is this simply missing?
well, it is more about augeas if it can handle it. I see https://github.com/hercules-team/augeas/blob/master/lenses/nsswitch.aug and last change knows about that merge action. Which is good. Also parser looks like allow any mixture of "service" and "reaction" so it should be possible. And looks like we are hit now by this TODO: https://github.com/yast/yast-pam/blob/master/src/lib/cfa/nsswitch.rb#L245 So we probably need to properly handle reactions there. Good part is that cfa is quite easy for regression testing, so create unit test that ensure proper format after mmodification should be easy ( the test, implementation is different question ).
Moved to our Trello task queue.