change default umask

The umask is what sets the default permissions for newly created files. Whonix has this set to 022 which gives read access to every user on the system for newly created files. 077 is recommended as it makes newly created files not readable by anyone other than the owner.

You can set the umask with the umask command. To set it as 077 by default, add umask 077 to /etc/profile and/or shell configuration files e.g. /etc/bash.bashrc.

It may be useful to add this to Whonix to prevent ordinary users from reading root owned files or a user reading another user’s files if someone has created more than one user.

1 Like

This may cause problems when accessing files in a shared folder. I don’t think it adds much compared to the higher yield kernel hardening you did.


The permissions for a shared folder could easily be changed with a simple chmod comand or with some file manager GUI if needed. I do agree that it doesn’t add much. It could help in some cases though.

1 Like

Could you post this as a feature request against Debian too please?

There is login shell vs non-login shell.

Quote )

Configuration file Type of setting Targeted user When applied Shell access type
/etc/profile Default setting All users including root While user login Login shell
/etc/bashrc Default setting All users including root While user access additional shell Non-login shell
/etc/profile.d/ Custom setting All users including root While user login and while user access additional shell. Both Login shell and non-login shell
/home/[user-name]/.bashrc Custom setting Individual user While individual user login and access additional shell Both Login shell and non-login shell

None of these files seem appropriate to set this setting. It does not really change the distribution default setting. For example it does not cover scripts such as those run during boot or Debian package maintainer scripts.

Where’s the default configured?

What’s the chance of introducing issues by changing this default?

1 Like


Systemd services can set their own umask with the UMask= option.

The package maintainer scripts will need to be done from upstream.

From the manpage:

The umask utility shall set the file mode creation mask of the current shell execution environment

There doesn’t seem to be anything other than shell config files or /etc/profile as it only sets it for the current shell.

This could be added to all of those files just to make sure.

There won’t be any major issues, the user may just need to change permissions of some newly created files some times. For most people, this likely won’t affect them.


Any update?

I forgot to create the feature request against Debian. Which package should it be?

1 Like


Can you make head or tail of File-system permissions - Wikipedia?

Looks like Debian previously discussed this a long time ago.

Perhaps package base-files but not without rehashing previous Debian discussions.

1 Like

It looks like there won’t be much difference between a umask of 002 or 077 as Debian puts users into their own private groups.

I doubt the devs would be willing to change the default umask, especially since they’ve discussed this before.

The umask change wasn’t rejected. They planned implementing it. Efforts then somehow stalled here mysteriously without explanation.

1 Like

Implementing this looks important. Login as some system or other user. For example start bash under user man.

sudo -u man bash

Then start snooping around.

cd /home/user

Not good at all.

1 Like

Let me describe in plain English what I would like to archive. Then please let me know if that is sane. The binary way to express it like 022 / 002 is rather confusing for me.

Newly created files should by default only be readable/writeable by the one who created it.

Looks like I like neither 022 / 002.
umask 077 seems nice to me.

umask 077
rm -f b && touch b && ls -la b

-rw------- 1 user user 0 Jun 29 14:26 b

umask 002 would result in:


Why would I want others (speak any user account) to have read access?

Why would I want group members (which group?) have read and write access?

1 Like

The user private group (UPG)? That seems needlessly complex to me.

Would anything break using umask 077 or is umask 077 discouraged for other reasons?

1 Like

Probably on a multi-user system where people share documents. Likely not good for Whonix though.

Since Debian uses UPGs, it will still only be the owner that has read-write access as they have their own private group. Newly created files are owned by the user’s group.

touch test
stat -c %G test


It is on anything other than multi-user systems.

Other users can’t easily access your files without you changing some permissions. That is a good thing for security, but bad for usability.

1 Like

lynis does not like umask 002 either.

Anyhow. Let’s go for umask 006 then?

umask 006
rm -f b && touch b && ls -la b

-rw-rw---- 1 user user 0 Jun 29 14:27 b

lynis would still complain but we can consider it a false positive and perhaps report a bug or reconfigure it if possible.

1 Like

umask 006 and umask 077 would be no different due to the UPG. It would be better to go for 077 so things like lynis won’t complain.



lynis complaining ins’t too bad.

  • complains about many things that probably don’t apply to us
  • we could report a bug
  • we could drop a config snippet if possible

Disadvantage of umask 077 would be that:

  • has no security advantage
  • breaks the standard / Debian default
  • could have unforeseeable bugs
  • users who are accustomed to things like addgroup someusername someusergroupsameasUPG for whatever they might be doing. Perhaps two different (server) applications that need to access each other’s home folder.

Therefore keeping the Debian default seems to take priority over output by lynis.

From reading the bug reports, to implement this, looks like the following has to be done.



UMASK		022


UMASK		006

/etc/pam.d/common-account and/or(?)


session optional usergroups

There are no drop-in config folders unfortunately?

Could you test this please? If it works, submit a pull request of these files against security-misc package? First, please submit the original file as per Debian buster unmodified. In another commit, amend the file.

Bonus: config-package-dev displace; debian/copyright / COPYING, but I can apply that on top too.

1 Like

It works fine. I created a pull request for them.

1 Like
diff /etc/pam.d/common-session etc/pam.d/common-session25,26c25,26
< session       optional 
< session       optional -c freezer,memory,name=systemd
> session       optional
> session optional usergroups

Looks like something went wrong. Unexplained change/diff compared to my Debian buster version. Will fix.

diff /etc/pam.d/common-session-noninteractive etc/pam.d/common-session-noninteractive 
< session       required 
< session       optional -c freezer,memory,name=systemd
> session       required
> session optional usergroups
1 Like
1 Like