Can I de-activate login shell for OS default id

[Prakarn]

I know these user id can not be delete from the system. However, To follow the security plolicy, I need to de-activate login shell as following id;
daemon,bin,sys,adm,uucp,lp,www

Please tell me how and what gonna effect to the system.


------------------------------
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
www:*:30:1::/home/www:/sbin/sh

[Patrick Wallek]

None of those id's should ever log in directly. You should put an invalid password, like the * character, as each id's pasword. This does effectively disable the id.

I would NOT change the home directory or the shell for the id as you might need to su to one the id's sometime.

[David Lodge]

Just change the shell to /usr/bin/false. There should *never* be a reason to log into these users directly.

I'd go further and say that you should uninstall UUCP and remove the uucp and nuucp users; but that's a risk you may not want to take.

[Bill Hassell]

If your system is not Trusted (that is, there is no directory /tcb) then they are already deactivated. The reason is that the encrypted password field is :*: and it is impossible to login with any password if the field is not exactly 13 characters long (up to, but not including the , character which is the optional password aging value). You can also disable any user login with :DISABLE: or :NOLOGIN: because the string is less than 13 characters.

If you have a Trusted system, the /etc/passwd file contains :*: for every user. That's because the encrypted passwords are stored in the /tcb directory. For either type of system (standard or Trusted), you can use the passwd -s command to see the status of a specific login or passwd -a -s to see everything. LK means locked.

[Steven E. Protter]

Nothing needs to be done.

It should be clear from the prior posts that no security issue exists.

The security policy has a high probability of messing you your system.

As Bill notes there is no possibility of these users loggin in, but they need to exist and should not be messed with.

I find it difficult to believe the policy writer knew a lot about Unix.

SEP