David Bolt wrote:

On Fri, 13 Mar 2009, L. V. Lammert wrote:-

...

On Fri, 13 Mar 2009, [UTF-8] Cristian Rodríguez wrote:

...

L. V. Lammert escribió:

...

Wow - thanks for pointing that out! Seems like somebody slipped up ROYALLY on this one - it was login enabled yet! No.

Perhaps not functionally, but there **IS** a valid shell in passwd - that makes a login possible.

Having a login shell doesn't mean it's possible to log in.

...

IMHO, best security practices dictate that accounts without login capability should have nologin as a shell.

/etc/passwd:suse-ncc:x:113:115:Novell Customer Center User:/var/lib/YaST2/suse-ncc-fakehome:/bin/bash ^ This means there is a password set and you can find the hash of it in /etc/shadow.

/etc/shadow:suse-ncc:!:13879:0:99999:7::: ^ By using this in /etc/shadow, it is impossible to log in as that user, or to use su to become that user without being root to begin with[0].

This is no big deal. HP and Sun have done similar things for years--their systems ship with invalid hashes for the vendor support login -- this allows a customer to enable/disable vendor access to the system without interfering with the customer's own internal processes. Typically the vendor access is also set up to sudo to root without the vendor needing to know the machine's root password. This allows very good security for the system -- a vendor's support specialist, or even kernal hacker can get system access (at the invitation of the customer vie phone call), while allowing the customer to cut off that access once the problem is resolved.

There's more info here:

<URL:http://www.cyberciti.biz/faq/understanding-etcshadow-file/>

with a short explanation in comment 2 of what ! or * in the password hash location means.

[0] On one of my 10.3 systems, the following "users" also exist with a valid shell, but who you would also not be able to log in as:

at bin daemon ftp games irc ldap lp mailman man news nobody tomcat uucp

And the reason for this is so that root can su to any of those system user id's for testing system software which runs under those ID's (or alternatively, to allow systems programmers to have access to those UIDs -- modify/replace only the software datafiles owned by those UIDs). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org