Bug 117202 - kuser destroys passwords if /etc/shadow not present (?)
Summary: kuser destroys passwords if /etc/shadow not present (?)
Status: CONFIRMED
Alias: None
Product: kuser
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR grave (vote)
Target Milestone: ---
Assignee: Szombathelyi György
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-28 14:40 UTC by Christopher Martin
Modified: 2019-06-07 10:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Martin 2005-11-28 14:40:49 UTC
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
Comment 1 Szombathelyi György 2005-12-02 21:34:31 UTC
If you don't have /etc/shadow, then clear the shadow file option in the config dialog.
Comment 2 Christopher Martin 2005-12-02 22:29:42 UTC
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.
Comment 3 Christopher Martin 2005-12-04 00:35:59 UTC
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
Comment 4 Szombathelyi György 2005-12-05 09:06:27 UTC
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.
Comment 5 Christopher Martin 2005-12-05 14:20:24 UTC
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.
Comment 6 Szombathelyi György 2005-12-07 08:16:08 UTC
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 ;)
Comment 7 Christopher Martin 2005-12-08 15:42:25 UTC
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.
Comment 8 Szombathelyi György 2005-12-09 08:04:49 UTC
I already added the checking for the shadow file, but I don't plan to parse /etc/login.defs or any other config file.
Comment 9 Szombathelyi György 2011-09-08 12:37:36 UTC
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!