(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 
- however, there is a simple fix for
this 
- 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.
