HP default users bin sys adm etc in /etc/passwd

[Jeong Jin-wook]

When I install hpux, there are several default users below.
Can anyone explain what each user does? or when each user is needed?

daemon:*:1:5::/:/usr/bin/false
bin:*:2:2::/usr/bin:/usr/bin/false
sys:*:3:3::/:/usr/bin/false
adm:*:4:4::/var/adm:/usr/bin/false
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:/usr/bin/false
www:*:30:1::/:
webadmin:*:40:1::/usr/obam/server/nologindir:/usr/bin/false

[Ivan Krastev]

All are the standart users, required from OS to operate properly.
Check only webadmin user.

What is your OS version?
Do you have webmin installed ?

regards,
ivan

[Jeong Jin-wook]

I use hpux 11.11.
I checked obam installed which related with webadmin.

OBAM B.11.00.05.3.04 Object Action Manager user interface framework for HP-UX tools

I want to know what each user does. Can anyone tell me?

[A. Clay Stephenson]

These users don't "do" anything and normally all of these accounts are locked so that it is not possible to login as one of these users. hpdb can be removed unless you are running the very old ALLBASE database software. Nobody (-2) is the NFS anonymous user. UID's -2 and 65534 are equivalent on most UNIX flavors (hint: think 16-bit two's complement integers).

www and webadmin are related to httpd. The remainder are standard system accounts. Consider that you have to have OS-related software and the files must belong to somebody. While it is possible that all of these could belong to root, that would be dumb because some of these need to be setuid and setuid root programs are an inherent risk and must be coded very carefully. If someone replaced a setuid program owned by daemon with a rogue program that would not be good but it would be far less bad than if it were owned by root. These are standard accounts and with the possible exceptions of hpdb, nobody, www, and webadmin, they should be left intact.

[whiteknight]

Jeong,

See:
http://docs.hp.com/en/B2355-90950/B2355-90950.pdf

chapter 8 page 750

root::0:3::/:/sbin/sh
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
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:



The key to the privileged status of these subsystems is their ability to
grant access to programs under their jurisdiction, without granting root
access (uid 0). Instead, the setuid bit for the executable file is set and the
effective user of the process corresponds to the owner of the executable
file. For example, the cancel command is part of the lp subsystem and
runs as effective user lp.

Once set, the security mediation of that subsystem enforces the security
of all programs encompassed by the subsystem, not the entire system.
Hence, the subsystemâ s vulnerability to a breach of security is also
limited to only that subsystem files. Breaches cannot affect the programs
under different subsystems. For example, programs under lp do not
affect those under daemon.

WK