Version: (using KDE KDE 3.4.2) Installed from: Debian testing/unstable Packages OS: Linux A Debian user has reported that kuser broke his system. He does not use shadow passwords (which is unusual, but not a policy violation) and so his system does not have the file /etc/shadow. His comments: *** Please type your report below this line *** When I attempted to add a new user (for testing purposes), kuser apparently replaced the password field in /etc/passwd with "x" for all users. It then reported it was unable to open /etc/shadow and exited. This left things so that no login by anyone was possible, which made it difficult to repair the damage! I don't use shadow passwords, and there is no /etc/shadow file present. I know of no Debian policy that requires /etc/shadow to be present. If kuser can't deal with a system where /etc/shadow isn't present, it should NOT leave the system unusable and unreparable. I suppose this is related to kuser editing files directly, as discussed in bug#248145. I have not checked what happens if /etc/shadow exists but "/sbin/shadowconfig off" has been executed, because I dislike the sensation of having all logins impossible. If kuser can't behave better, then I think the Debian installation should at least check for the existence of /etc/shadow and, if it's not present, at least warn the user during installation of potential disaster. ********* I'll admit to not having tested the situation thoroughly, not wanting to risk messing things up. I was hoping you could evaluate the problem, and either patch it or explain why it's not valid, etc. Thanks for your help, Christopher Martin
If you don't have /etc/shadow, then clear the shadow file option in the config dialog.
Granted, but when dealing with such an important part of the system, some automatic checks to prevent forgetful users from messing up would be very welcome.
I see: --- SVN commit 484993 by gyurco: Fix a crash in the user dialog where shadow passwords are disabled. Also switch to shadowless mode when shadow file not found. However it's just for confort, it's desired to clear the shadow file name in the config dialog when shadow file not used. --- But what about situations where /etc/shadow is present but shadow passwords have been turned off using /sbin/shadowconfig ? It isn't obvious to the user that the presence of /etc/shadow in the config dialog makes kuser use shadow passwords. This really ought to be improved further. Also, it would be really nice if you could backport these fixes to the 3.4 branch (and maybe even 3.3). Thanks, Christopher Martin
The real problem is (in your point of view) that KUser doesn't use the config files as adduser & Co. But KUser will not do that in the future, since it would be very platform-dependent and error-prone. If you don't want to use shadow file, then please configure KUser to not use. It's very simple, just clearing some text from an editbox. I think if an user (or admin) is advanced enough to disable shadow support, she/he might clear an editbox.
I understand that KUser doesn't plan to use adduser. All I'm requesting is an additional check or two to ensure that users who for whatever reason don't use shadow passwords can't mess up their systems so easily. Some people may not even remember whether or not they're using shadow passwords, and simply assume that KUser is smart enough to figure it out itself. Also, it is NOT obvious that clearing an edit box is the same as disabling the shadow password abilities of KUser. This is NOT what dialog boxes normally do. They just contain default information that may or may not be used. Enabling/disabling features is what (for instance) checkboxes are for.
You're might be right, a checkbox could be more self-commenting, but I think it's a very rarerly used option, so I'll lazy to add it...However I'll accept a patch ;)
Beside the checkbox issue, do you plan to add any further checks to ensure that when the user isn't using shadow passwords, either because the file isn't there, or because shadowconfig is off, that the system isn't messed up? To me, this is still the most important aspect of this bug.
I already added the checking for the shadow file, but I don't plan to parse /etc/login.defs or any other config file.
What I can imagine solving this: Using the 'system' backend for managing users/groups can be extended to modify users/groups via external scripts (like useradd, groupadd, etc...). Currently it's a read-only backend, so it would be a nice addition. Patches are welcome!