Private home directories for Ubuntu 21.04 onwards?

(Cross-posting from the email to ubuntu-devel-discuss earlier)

After more than 14 years of debate, I propose that it is time we moved ahead and stopped creating home directories as world-readable on Ubuntu for hirsute (21.04) onwards. The old arguments from the bug referenced in the launchpad bug mainly centered on the convenience of this feature when considered in regards to a shared desktop machine with multiple user accounts wanting to easily share files with one-another. However, a lot of things have changed in the last 14 years, not least of which that Ubuntu has a significant customer and user-base in the public cloud and server space. For these users, there is generally 1 admin account and perhaps a number of less privileged worker accounts, and so world-readable home directories now present more like a footgun than a feature - in this case, if a worker account is compromised, an attacker could now more easily access sensitive data from the other worker accounts or the admin account.

Whilst the Ubuntu Security team does a great job of staying on top of security updates and keeping the distro packages as secure as possible, there will always be instances where for whatever reason machines are not kept up-to-date or weak passwords are used and so they become compromised. We should therefore be taking an approach to limit access in this unlikely event.

The other part of the past argument for this was that knowledgeable users / sysadmins will be aware of this default and will change it if they deem necessary. Whilst I am sure that we do have many knowledgeable users, we have many more who simply are deploying Ubuntu to solve other tasks - and I think it goes against the usability proposition of Ubuntu in these cases to expect admins to make this change. Instead we can ensure these deployments limit the chance for sensitive information to be compromised by changing this default.

It should be noted too that from a regression point-of-view, changing this default will also not affect any permissions on existing installs (if it was perhaps decided to SRU this change back to older releases) or on upgrades - only if new users are created will they then have these more restrictive permissions. By making this change now, this also gives 3 development releases and 2 interim releases to work through any unforseen issues etc before landing in an LTS release. Without some widespread testing it is not possible to know in advance all of the possible use-cases that have depended on this behaviour which may then have issues so I feel now is the time to make such a change so we can determine any appropriate work-arounds and associated documentation etc as needed.

As such, for a concrete proposal, I suggest changing /etc/adduser.conf to specify DIR_MODE=0750 instead of the current DIR_MODE=0755 - this will ensure any users created via adduser have their home-directory non-readable and non-executable by others.

In the case of useradd (the low-level util) this is a bit trickier - whilst the documentation suggests we can set HOME_MODE in /etc/login.defs this does not appear to be respected and only if we set say UMASK=027 in /etc/login.defs and then create a user (useradd -m -d /home/test test) does the home dir have the expected permissions. However, modifying the default umask has other consequences so I am not suggesting we consider that at this point. So this will need some more investigation, for now I would like to focus on adduser as this is the documented approach for adding new Ubuntu users .

If you want to try this yourself, you can simply:

# ensure future users homes are safe
sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf

# then get your own house in order
chmod 750 $HOME

In regards to things to watch out for, one use-case that I have come across myself is libvirt VMs where the disk image is stored in your home directory - these become unreadable now to the libvirt-qemu user and so you can’t launch these anymore :slightly_frowning_face: - however, there is a simple fix for
this :slightly_smiling_face: - you can use an ACL entry to re-enable this access for just the libvirt-qemu user:

setfacl -m u:libvirt-qemu:rx $HOME

(or you could just store your images under /var/lib/libvirt/images)

I suspect this ACL approach may be needed for other common use-cases but like I said above this remains to be seen so any testing others could give of this would be really appreciated in helping to decide whether to try and proceed with this change.

Finally, if there is a strong case for deployments who rely on the existing functionality (say universities etc) where having to manually roll-back the setting on each machine install would be painful, we could look at adding some functionality to the installer/preseed/whatnot to create initial users etc with the old permissions.

Thanks for taking the time to read this - any constructive feedback is welcome.


Just to follow up on this thread - since there was no opposition to this proposal, I have uploaded updated adduser and shadow packages to hirsute-proposed to support setting the mode of home directories to 750 by default when they are created via either adduser or useradd.

Let me know if you encounter any significant issues :slight_smile:


So can be marked as fixed rather than as invalid? :wink:

Thanks for raising that - I’ve marked that bug as a duplicate of the original “primary” one mentioned in the first post in this thread and updated that primary with the current status.

1 Like

One (rather old) feature impacted could be apache web server userrdir support
(~/user web, mapped to /home/user/public_html).

It was a '90s “feature”. I hope deprecated.

cron, mail, lp taken a different approach: user dirs under /var/spool

User namespaces are impacted?

Docker/Podman, Snap/Flatpak, Selinux/AppArmor ?

Mode 750 may be too permissive (if users are in ‘users’ default group),
To share files, ‘002’ is good for umask (and setgid on dirs)

Anyway, something must be done

this do not work (ok):

find ../myrichclassmate/Dropbox -name '*bank*'

cat ../a.sysadmin/.ssh/id_rsa

but this works ! (NOT ok):

find ../myexfriend/Videos -name '*my-secret-videos*'

under ‘~/snap’ some credential store (git http) ?

Snaps themselves should actually be ok because we use “owner” match in the AppArmor policy. This change should only mean that DAC rejects it before AppArmor does if a snap run by one user tries to access files in home from another user.

I do not know what happens in hybrid envs:
Snap+selinux (redhat) vs Flatpak+AppArmor (ubuntu).
Probably acces to “…/another/snap/*” is restricted at application level (like “advisory locking”…)

One point is not clear to me:

With “podman” you can have rootless containers, where container root is mapped to running user, with images stored under ~/.local (with restricted access).
But, if inside the container the process owner changes, it will be mapped by namespace user mapping to a different os user, without any special privileges.
If the user home is restricted, containers cannot “see” volume binding inside home.
How can this work?
I need to enable container based development under full user control in untrusted multiuser env (hpc classrooms)

I think you should highlight a very common problem with encrypted home directories: openssh-server can’t see ~/.ssh/authorized_keys files, thus SSH log in does not work by default.

I usually resolve that by moving SSH authorized_keys files to /etc/ssh/users/%u, but that does not work for the general case (because /etc might be mounted read-only).

1 Like


Telegram and many other purple plugins, (and evince) is now do not work unless I modify that apparmor settings or restore it to 755. Please try to fix most common problem before landing something like this.

What are your suggestion regarding this?

@zippy.zebu can you either file bugs for these issues or at least provide more information on the errors etc that you see, then I can try and help?

A common situation is to have a central set of users (e.g. in LDAP) and use to create the home directory when the user first logs in.

These changes do not cover this situation. The default configuration of will result in a home directory created with 0755 permissions.

To make create a home directory by default with permissions consistent with the other tools then a umask argument can be added to the module in the file /usr/share/pam-configs/mkhomedir. I believe this would have to be done before enabling the module. The file is part of the libpam-modules package.

1 Like

Thanks for the info re pam-mkhomedir - I have filed a bug on launchpad ( to track this. If you can provide any info on a test-case for this, could you please do so in a comment on that bug report? Thanks.

1 Like