I installed on my pi a web server with everything I want, now I want to know for sure that my server is secure. I started to check for useless accounts, I found a lot account in my Debian installation:


Where are all those accounts for? I guess to run jobs? But how do I know if someone from the outside can login with the default password on that account? I don't want the someone can FTP to my PI with the ftp user.

1 Answer 1


http://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html Are all system users necessary?

Yes and no. Debian comes with some predefined users (user id (UID) < 99 as described in Debian Policy or /usr/share/doc/base-passwd/README) to ease the installation of some services that require that they run under an appropriate user/UID. If you do not intend to install new services, you can safely remove those users who do not own any files in your system and do not run any services. In any case, the default behavior is that UID's from 0 to 99 are reserved in Debian, and UID's from 100 to 999 are created by packages on install (and deleted when the package is purged).

To easily find users who don't own any files, execute the following command[80] (run it as root, since a common user might not have enough permissions to go through some sensitive directories):

   cut -f 1 -d : /etc/passwd | \
   while read i; do find / -user "$i" | grep -q . || echo "$i"; done

These users are provided by base-passwd. Look in its documentation for more information on how these users are handled in Debian. The list of default users (with a corresponding group) follows:

root: Root is (typically) the superuser.

daemon: Some unprivileged daemons that need to write to files on disk run as daemon.daemon (e.g., portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users. The daemon user is also handy for locally installed daemons.

bin: maintained for historic reasons.

sys: same as with bin. However, /dev/vcs* and /var/spool/cups are owned by group sys.

sync: The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have don't have an account.

games: Many games are SETGID to games so they can write their high score files. This is explained in policy.

man: The man program (sometimes) runs as user man, so it can write cat pages to /var/cache/man

lp: Used by printer daemons.

mail: Mailboxes in /var/mail are owned by group mail, as explained in policy. The user and group are used for other purposes by various MTA's as well.

news: Various news servers and other associated programs (such as suck) use user and group news in various ways. Files in the news spool are often owned by user and group news. Programs such as inews that can be used to post news are typically SETGID news.

uucp: The uucp user and group is used by the UUCP subsystem. It owns spool and configuration files. Users in the uucp group may run uucico.

proxy: Like daemon, this user and group is used by some daemons (specifically, proxy daemons) that don't have dedicated user id's and that need to own files. For example, group proxy is used by pdnsd, and squid runs as user proxy.

majordom: Majordomo has a statically allocated UID on Debian systems for historical reasons. It is not installed on new systems.

postgres: Postgresql databases are owned by this user and group. All files in /var/lib/postgresql are owned by this user to enforce proper security.

www-data: Some web servers run as www-data. Web content should not be owned by this user, or a compromised web server would be able to rewrite a web site. Data written out by web servers, including log files, will be owned by www-data.

backup: So backup/restore responsibilities can be locally delegated to someone without full root permissions.

operator: Operator is historically (and practically) the only 'user' account that can login remotely, and doesn't depend on NIS/NFS.

list: Mailing list archives and data are owned by this user and group. Some mailing list programs may run as this user as well.

irc: Used by irc daemons. A statically allocated user is needed only because of a bug in ircd, which SETUID()s itself to a given UID on startup.


nobody, nogroup: Daemons that need not own any files run as user nobody and group nogroup. Thus, no files on a system should be owned by this user or group.

Other groups which have no associated user:

adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

tty: TTY devices are owned by this group. This is used by write and wall to enable them to write to other people's TTYs.

disk: Raw access to disks. Mostly equivalent to root access.

kmem: /dev/kmem and similar files are readable by this group. This is mostly a BSD relic, but any programs that need direct read access to the system's memory can thus be made SETGID kmem.

dialout: Full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc.

dip: The group's name stands for "Dial-up IP", and membership in dip allows you to use tools like ppp, dip, wvdial, etc. to dial up a connection. The users in this group cannot configure the modem, but may run the programs that make use of it.

fax: Allows members to use fax software to send / receive faxes.

voice: Voicemail, useful for systems that use modems as answering machines.

cdrom: This group can be used locally to give a set of users access to a CDROM drive.

floppy: This group can be used locally to give a set of users access to a floppy drive.

tape: This group can be used locally to give a set of users access to a tape drive.

sudo: Members of this group don't need to type their password when using sudo. See /usr/share/doc/sudo/OPTIONS.

audio: This group can be used locally to give a set of users access to an audio device.

src: This group owns source code, including files in /usr/src. It can be used locally to give a user the ability to manage system source code.

shadow: /etc/shadow is readable by this group. Some programs that need to be able to access the file are SETGID shadow.

utmp: This group can write to /var/run/utmp and similar files. Programs that need to be able to write to it are SETGID utmp.

video: This group can be used locally to give a set of users access to a video device.

staff: Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group "adm", which is more related to monitoring/security.

users: While Debian systems use the private user group system by default (each user has their own group), some prefer to use a more traditional group system, in which each user is a member of this group.

  • 2
    If I could, I would give you all my up-votes from today. Thanks!
    – Laurence
    Nov 20, 2012 at 15:27
  • 1
    @Darkmage Do you know the other answer for Laurence? how do I know if someone from the outside can login with the default password on that account?
    – Iain
    Nov 21, 2012 at 2:25
  • 2
    @Iain If the default shell is set to /bin/nologin, then the account is disabled to external login.
    – Jivings
    Nov 21, 2012 at 7:44
  • 1
    @lian by default no other then system or root can access these accounts. But if a hacker gets in to you system any other way they can be edited or changed to make for a easy backdoor account. So your main objective is to keep the intruder out because if he gets in, he can hide hes backdoor way harder to find then a predefined user. so don't worry so much about those.
    – Darkmage
    Nov 21, 2012 at 9:10
  • 2
    like Jivings says if a user is tagged with shell "/bin/nologin" and "/bin/false" in the "/etc/passwd" file it shows that is cant be accessed.
    – Darkmage
    Nov 21, 2012 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.