Bug 623432

Summary:	su from root fails for locked accounts
Product:	[openSUSE] openSUSE 11.3	Reporter:	Nathan Robertson <nathanr>
Component:	Security	Assignee:	Philipp Thomas <pth>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P2 - High	CC:	gassauer, kukuk, security-team
Version:	Final
Target Milestone:	---
Hardware:	All
OS:	openSUSE 11.3
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Nathan Robertson 2010-07-19 12:11:10 UTC

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100506 SUSE/3.5.10-0.1.1 Firefox/3.5.10

I've managed to reproduce bug #556077 on openSUSE 11.3. It's claimed in that bug that it was fixed in 11.2, but I can reproduce it under 11.3.

Reproducible: Always

Steps to Reproduce:
linux-07mr:~ # useradd -m -d /opt/test -g postgres test  
linux-07mr:~ # su - test  
su: incorrect password  
linux-07mr:~ # passwd test  
Changing password for test.  
New Password:   
Bad password: too short  
Reenter New Password:   
Password changed.  
linux-07mr:~ # su - test  
test@linux-07mr:~>

another use case:
linux-07mr:~ # useradd -m -d /opt/test -g postgres test  
linux-07mr:~ # grep test /etc/shadow  
test:!:14809:0:99999:7:::  
linux-07mr:~ # vim /etc/shadow  
linux-07mr:~ # grep test /etc/shadow  
test:*:14809:0:99999:7:::  
linux-07mr:~ # su - test  
test@linux-07mr:~> 

Actual Results:  
Can not su from root to another non-root user which has a disabled account where there is a "!" for the password. Works fine where "*" is the password, as per bug #556077

Expected Results:  
Should be able to su as root to a disabled account.

As noted in bug #550677, this stops the PostgreSQL initdb scripts from working. For us, it's EnterpriseDB PostgresPlus Standard installer, which works fine on SLES 11 SP1, but not on openSUSE 11.2 or 11.3. They do a "useradd" then an "su" to the created user, which fails.

Comment 1 ferdinand gassauer 2010-07-22 06:48:26 UTC

as it prohibits "normal" use of all databases (mysql and postgres) and may be others services this should be fixed ASAP
it's not production ready to ask end users to fiddle around in /etc/shadow to replace '!' by '*'

Comment 2 Michael Calmer 2010-07-26 08:57:38 UTC

Thorsten added account-mgmt support in pam_rootok.so . So the solution would be to add 

account sufficient pam_rootok.so 

to /etc/pam.d/su-l

Don't know if this is a good idea to change the pam config file within a release.
This is a decision of the coreutils maintainer.

Thorsten: any comment on this?

Comment 3 Thorsten Kukuk 2010-08-02 09:38:06 UTC

The behavior is correct and the expected one by definition.
Please read the useradd manual page and fix your useradd command for postgres. You need to create a system account if it should be without password and root be able to su into it.

Comment 4 ferdinand gassauer 2010-08-02 20:15:20 UTC

thanks for pointing out

FYI the behaviour must have changed between 11.2 and 11.3, because my installation worked before and didn't work any more after update.

BTW
man:/useradd - 
-r, --system 
 Create a system account. A system account is an user with an UID between SYSTEM_UID_MIN and SYSTEM_UID_MAX as defined in /etc/login.defs, if no UID is specified. The GROUPS entry in /etc/default/useradd is ignored, too.

IMHO this is not helpful for this issue, it does not explain the issue and I wouldn't know why a user or admin should useradd the user postgres - this account was available "forever" and should be fixed in the distributed rpm.

Comment 5 Thorsten Kukuk 2010-08-02 20:32:43 UTC

(In reply to comment #4)
> thanks for pointing out
> 
> FYI the behaviour must have changed between 11.2 and 11.3, because my
> installation worked before and didn't work any more after update.

Exact the same issue with EnterpriseDB PostgresPlus Standard installer was already reported before 11.2 was released. So this has not changed between 11.2 and 11.3, but the root is a bug fix in handling of shadow passwords before 11.2. For plain /etc/passwd systems, the current behavior was already the default for ever, only /etc/shadow handling did contain a bug.