I want to prevent users being able to see other system users. I've prevented listing of processes with hidepid=2 mount option to /proc, prevented listing of other users' home directories, but they can still see what users are there by doing "getent passwd" or "cat /etc/passwd".

Is "chmod 640 /etc/passwd /etc/group" safe to do? What can potentially break? Running Ubuntu 20.04 or 22.04.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Oct 8, 2022 at 10:52

3 Answers 3


Based on your comment:

This is a webserver hosting many websites - and usernames/group names contain the names which allow to identify which websites are running on the server. I.e. a username can be "example.com", or "example.tld" (or similar, which allow to figure out the full domain name). Because the sites run similar software - if one site is hacked due to some vulnerability - the attacker could enumerate the sites running on the server and infect them using the same vulnerability. Hiding the ability to simply list the domains makes it harder for the attacker, and gives more time for website owners to update.

I'd say that what you want to do is provide some sort of (poor) security through obscurity.

If an attacker hacks a website, most likely they get a root shell, so 1) the whole server is compromised and 2) having gained privileged access, they can get the full list of users anyway.

On top of that, restricting permissions from system configuration files is always a bad idea. You never know what (and when) will break.

  • In addition, if your webserver uses www-data (or apache) the webserver must be able to see data of all users. Think about dynamic pages. So one can see all data with PHP (and BTW there are also shell that run in PHP, so restricting shell access usually is not useful). So: either you trust your users (also not overriding data, but so you should trust no vulnerability), or you must find a different way. Oct 5, 2022 at 12:07
  • 8
    I disagree with "if a site gets hacked, they get a root shell". In my experience, most site exploits work because some popular software (Wordpress, Joomla, their extensions or themes etc.) have a working exploit and it actively exploited by bots. Root exploits are extremely rare (given the system is sufficiently updated). Most of the time, the attackers want to: 1) send spam, 2) add website redirects to boost their google rankings or direct people to their scammy sites - root escalation is not needed for that, and even makes their detection more probable (the server may hang etc.).
    – Tomasz
    Oct 5, 2022 at 18:48
  • 1
    "if your webserver uses www-data" It's not. It's using php-fpm, every website has its own system account. Actually, that's more complicated. Apache DOES run as www-data, but since it can't execute anything, you can't make it read other user files (that's what's php-fpm is for).
    – Tomasz
    Oct 5, 2022 at 19:58

So far, these break:

  • "ls -l" - displays uids/gids - no big deal (at least for me!)

  • OpenSSH's ssh command - i.e.:

$ ssh [email protected] -v
No user exists for uid 1166
$ echo $?

It doesn't even attempt to establish a connection!

There is a workaround for that - using an alternative SSH client, like dropbear (dbclient):

$ dbclient [email protected]
dbclient: Warning: failed to identify current user. Trying anyway.
(...connection succeeds...)
  • subversion (which uses ssh):
$ svn st -u
No user exists for uid 1166
svn: E170013: Unable to connect to a repository at URL ...

Workaround - editing /etc/subversion/config, [tunnels] section - and using dropbear's dbclient, not OpenSSH's ssh:

# ssh = $SVN_SSH ssh -q -o ControlMaster=no --
ssh = $SVN_SSH dbclient -q -o ControlMaster=no --
  • other software using OpenSSH's ssh - similar workaround should help

/etc/passwd and /etc/group both have permissions

-rw-r--r--. 1 root root

that means the owner = root, and the group is root.

so doing chmod 644 on either to remove world readable ability will break the system... for whatever processes or services that are not in the root group, which they should not be (hopefully for obvious reasons), will not be able to read info out of those files regarding uid and gid probably being the two biggest ones. The whole linux OS operates on uid and gid and what accounts have what... that is not really a security vulnerability that you need to worry about.


  • Sensitive data in modern UNIX systems is kept in /etc/shadow file.
  • what's in /etc/passwd is not sensitive data.

however I think this is a good question, from a certain perspective if you have whatever reason to disallow users from being able to know all user accounts on the system from simply seeing it in /etc/passwd. Then again wouldn't you also want to prevent doing an ls -l and gleaming user information that way? Is a potential solution to use LDAP where such LDAP accounts would not be present in /etc/passwd?*

  • 1
    getent passwd will still show LDAP accounts unless you turn enumerate off. You can also get a (partial) list of user accounts but running ps -ef. This is security by obscurity and a more secure method of hiding sites needs to be implemented.
    – doneal24
    Oct 5, 2022 at 15:46
  • Seeing other users' processes in ps output can be prevented with "hidepid=2" mount option to /proc filesystem.
    – Tomasz
    Oct 5, 2022 at 18:50
  • 1
    How would ls -l or ps -ef help getting the names associated with the UIDs? Also this answer doesn't really seem to explain what exactly would break if that mapping couldn't be made. (and they did ask "What can potentially break?" (emphasis mine), which seems to imply a request for specifics not just groundless fluff.)
    – ilkkachu
    Oct 5, 2022 at 19:42
  • in company/corporate work setting the employee badge number is often used as the linux UID and is also present in the account name; convenient should a username be deleted and left over files show uid instead of username for ownership; for ls - seeing ownership of files with lastname_letterfirstname lets you know who has accounts on your system...
    – ron
    Oct 5, 2022 at 19:54
  • 1
    @Tomasz That's still security through obscurity, having only execute (no read) access on a directory doesn't stop anyone from enumerating its entries simply by trying all combinations (cd /home/a, cd /home/b, …, cd /home/aa, …) which can be done reasonably quickly locally
    – TooTea
    Oct 6, 2022 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .