Bugzilla – Bug 148464
new user with password "x" disabled
Last modified: 2006-07-26 07:43:43 UTC
in yast at install time I created a user "koenig" with password "x" (1 character). I got a warning about short password and a 2nd warning about only using lower case charaters. pressing ENTER twice created the user account, but it's disabled: # grep koenig /etc/shadow koenig:x:13182:0:99999:7:-1::
As usual: attach the y2logs, please ;-) BTW: Does this also happen with password "y"? Just to make sure it's disabling the user and not missing encryption...
(In reply to comment #1) > As usual: attach the y2logs, please ;-) > > BTW: Does this also happen with password "y"? Just to make sure it's disabling > the user and not missing encryption... sorry, the y2logs for beta-2 installation are gone, I've installed beta-3 in the mean time. and for the 1st time I've used the password "xy" for my local test account, and this time the account worked out of the box (was not blocked). at least in 10.0 and almost sure 9.3 (maybe even earlier) had the same behaviour that password "x" for root was ok, but the plain user with "x" always was disabled after installation. looks like you have some special code in yast for password "x", maybe I should use the even more secure new password "y" in the future ?! ;-)
(In reply to comment #1) > As usual: attach the y2logs, please ;-) > > BTW: Does this also happen with password "y"? Just to make sure it's disabling > the user and not missing encryption... is it possible to trigger/test that behaviour without starting a new installation ? right now a new installation is not possible -- no free resources, sorry :-(
It should be reproducible easily, reassigning. A root password with a single character is really no good idea... maby the password should just be rejected and at least be 3 chars long, which is unsecure enough as I think.
Unfortunatelly, "x" password just doesn't work and it is not so easy to fix it.
(In reply to comment #4) > A root password with a single character is really no good idea... maby the > password should just be rejected and at least be 3 chars long, which is > unsecure enough as I think. oh come on, please. if I decide that this is secure enough and click "OK" in two message boxes with warnings, you really can beleave me that "x" is secure enough in this case. after all, this system doesn't have a real network connection and you'll have some trouble to get physical acesss to it -- and it's only my play ground right now to figure out if it's really possible to use 64 bit XEN with SUSE -- right now the estimated answer seems to be "no" anyway (deep sigh:-( if you'd like to improve security, you better remove the default for the "automatic login" stuff without any password at all -- even if this might set up some WinXP SP0/SP1 users...
(In reply to comment #5) > Unfortunatelly, "x" password just doesn't work and it is not so easy to fix it. I always waas afraid, that once this password might break my neck -- now it seems to have happened ;-) "not so easy to fix" sounds really scary, maybe one should look into the depths of user administration/creation and password stuff for some code review :-)) OK, learned my lessen: I will switch to password "y" for future testing ! thanks!!
ad comment #6: it has nothing to do with security, it is a real bug "not so easy to fix" means it is not few-line fix; however I want to solve it. By this statement I alse meant that I won't have a time to fix it for 10.1 setting as LATER
reopen yast2-users bugs
Stano, please move this to FD as mandatory features for SP1.
later (->feature document)
reopened
Fixed in yast2-users-2.13.21