I just added a new, underprivileged "desktop user," and I was surprised to discover that it can see the files in my home folder.

What is the rational for setting up such lax permissions?


7 Answers 7


A Public folder exists in your Home directory (/home/user) for sharing files with other users. If an other user wants to get access to this Public folder, the execute bit for the world should be set on the Home directory.

If you do not need to allow others to access your home folder (other humans or users like www-data for a webserver), you'll be fine with chmod o-rwx "$HOME" (remove read/write/execute from "other", equivalent to chmod 750 "$HOME" since the default permission is 750). Otherwise, you should change the umask setting too to prevent newly created files from getting read permissions for the world by default.

For a system-wide configuration, edit /etc/profile; per-user settings can be configured in ~/.profile. I prefer the same policy for all users, so I'd edit the /etc/profile file and append the line:

umask 027

You need to re-login to apply these changes, unless you're in a shell. In that case, you can run umask 027 in the shell.

Now to fix the existing permissions, you need to remove the read/write/execute permissions from other:

chmod -R o-rwx ~

Now if you decide to share the ~/Public folder to everyone, run the next commands:

  • chmod o+x ~ - allow everyone to descend in the directory (x), but not get a directory listing (r should not be added)
  • find ~/Public -type f -exec chmod o+r {} \; - allow everyone to read the files in ~/Public
  • find ~/Public -type d -exec chmod o+rx {} \; - allow everyone to descend into directories and list their contents

If you are use GNU coreutils (e.g. on Ubuntu, not on a embedded system having only busybox), then the previous two commands using find and chmod can be replaced by this single command that recursively makes folders and files readable (and additionally adds the execute (descend) bit for directories only):

chmod -R o+rX ~/Public
  • execute bit sure, but why read? I mean you dont need to list all the contents of the folder and one also definitely doesnt need rx for world on all the home folder's contents
    – My1
    Jul 11, 2020 at 18:05
  • @My1 The answer suggests adding x only for the home folder, not r. It suggests making all files and directories readable in the public folder. All other directories (e.g. ~/Documents) remain private if their mode is properly restricted (e.g. 750).
    – Lekensteyn
    Aug 2, 2020 at 14:30
  • I wasnt referring to any suggestion but the initial explanation: "If an other user wants to get access to this Public folder, the execute bit for the world should be set on the Home directory." and my question is why is the read bit then needed. I mean I have a "global mount" folder which gets only triple x as permissions so the things cant be iterated all that easily, doubt it'll do much but I have seen setups where you cannot list the contents of folders but can get into the folder
    – My1
    Aug 3, 2020 at 15:03
  • Be careful when you change the permissions of all files in $HOME, otherwise ssh won't work anymore until you fix permissions for $HOME/.ssh E.g. private key files need chmod 600
    – crs
    Apr 1, 2021 at 11:13

Ubuntu 21.04 and later releases have a secure default, see this blog article (archived link) linked by stackprotector in the comments section:

for new installations of Ubuntu 21.04, or for users created on a machine that has been upgraded to Ubuntu 21.04, home directories will be private by default.

However, the article implies that users created on Ubuntu < 21.04 will not be fixed automatically, even after applying security updates or upgrading to Ubuntu 21.04 or later. These users can be corrected by hand, with the following commands taken from the article.

To fix all existing users:

sudo chmod 750 /home/*

To fix the default for users that will be created in the future:

sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf
echo "HOME_MODE 0750" | sudo tee -a /etc/login.defs

For Ubuntu < 21.04:

According to Mark Shuttleworth, Canonical's founder and CEO,

"The majority of users of Ubuntu systems either have exclusive use of the machine (personal laptop) or are sharing with friends and relatives. We assume that the people who share the machine are either trusted, or in a position to hack the machine (boot from USB!) trivially. As a result, there is little to no benefit"

... from removing those permissions.

  • 19
    I think having the same behavior in the Server edition is a security hole
    – warvariuc
    Mar 28, 2015 at 6:55
  • 6
    That is a crazy explanations. Other than people accounts there are technical accounts that people can use to isolate applications. Additionally there is a lot of instructions on how to set up a local ftp server that essentially shares the account on the machine. Oct 11, 2015 at 14:51
  • 5
    I know this is old thread, but consider this as stupid decision. Imagine one of the users run app/script (can be unintentionally) which is able to read and send files from any other profile.
    – mauron85
    Apr 12, 2017 at 11:25
  • @warvariuc, please put your opinions on the official bug report, bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734, so this behavior can change any time soon. Apr 6, 2020 at 2:47
  • Our prayers have been answered: ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 (archived link) Sep 2, 2021 at 12:04

According to an Ubuntuforms.org staff member, it is to make it easier to share files between new users.

You can change the permission to either 700 or 750 if you don't want the files readable and executable by others.

Command is:

chmod 750 $HOME

Note: Ubuntu default is 755


You can read the User Management section of the Ubuntu Server Guide which covers the necessary details. The User Profile Security paragraph will probably answer your questions - officially.

  • 5
    I appreciate the official source. Sadly, though, it doesn't look like it provides any justification.
    – ændrük
    Jun 10, 2011 at 4:10
  • Look at @ignis response for the official justification. Apr 6, 2020 at 2:49

I think Lekensteyn's answer can be improved by replacing the last two find commands with chmod using -X option (note the capital X). The two find commands can be replaced with

chmod -R o+rX ~/Public

This differentiates appropriately between files and directories, but does have the additional effect of allowing others to run executable files.


Since it is privacy that interests you (judging from the tags that were applied) it is very possible that setting permissions is insufficient (see ignis's answer). The answer may be something along the lines of an encrypted home directory. This solution is specifically designed against the attack by another user of a computer. It will, of course, be unable to stop another user from damaging your files (by simply removing ~/.Private directory, thus erasing all of your files), but they will be unable to mount the directory and see the files without your password.

The easiest way to achieve that is during the installation process, there is a check box, stating "Encrypt your home directory" and you need to select that.

Since it is unlikely that you will want to reinstall just for that (and because it still carries all the risks that are entailed with doing it without reinstall), you can do the following:

sudo apt-get install encryptfs-utils

If you really need a high level of security: please re-install and make sure to choose the option to encrypt your entire disk. This will require a passphrase to even start the machine. You may of course also encrypt your home folder once more on top of this, with some performance degradation; though not noticeable for normal use.

Please note, that encrypting your home folder will disable applications like Dropbox. Dropbox is not secure storage that respects privacy anyway, so that may be a trite point. However, if you do need secure and private storage in the cloud, I would personally recommend MEGAsync since only you would have the keys to access the data.

You must log in to answer this question.

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