[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

change default umask

config-package-dev displace and copyright is sorted.

1 Like

This needs to be re-checked with every distribution upgrade. For example systemd causes an issue:


This might be inconsistent depending on from where files are created. Could you please test all of the various options?

  • sudo su
  • sudo -u man bash
  • sudo su
  • sudo login
  • sudo sulogin
  • virtual console
  • boot emergency console (maintenance mode)
  • from scripts
  • any any others that you might have in mind?
1 Like

This got me 0026 instead of the expected 0006. Same for sudo sulogin too.

The rest were all fine.

1 Like

So we have two programs/packages that ignore umask.

dpkg -S `sudo which sulogin`
util-linux: /sbin/sulogin

And

dpkg -S `sudo which sudo`
sudo: /usr/bin/sudo

Could you please check if there are bug reports / report bugs / find workaround for these?

1 Like

I can’t find anything. Maybe it’s just a thing on my end. Does the issue replicate for you?

1 Like

Same issue for me.

ls -la a
-rw-rw-r-- 1 root root 0 Jul 1 11:30 a
ls -la a
-rw-rw-r-- 1 root root 0 Jul 1 11:30 a

1 Like

We should probably make a bug report then.

1 Like
1 Like



1 Like

Still getting this error.

Jul 07 22:29:11 host sudo[4089]: PAM unable to dlopen(pam_cgfs.so): /lib/security/pam_cgfs.so: cannot open shared object file: No such file or directory
Jul 07 22:29:11 host sudo[4089]: PAM adding faulty module: pam_cgfs.so

Do we need to depend on package https://packages.debian.org/buster/libpam-cgfs?

Or what is line

session optional pam_cgfs.so -c freezer,memory,name=systemd

in our https://github.com/Whonix/security-misc/blob/master/etc/pam.d/common-session.security-misc good for? It’s a Debian default, right? So I am wondering why I never saw this bug before.

1 Like

Removing the pam_cgfs.so line or installing libpam-cgfs fixes the error.

It seems to be useful for creating cgroups and unprivileged containers like with LXC.

1 Like

Added dependency so we can stay as close to upstream default as sanely possible.

1 Like
1 Like

Since users who upgraded don’t benefit from these default umask changes (files already created using Debian default umask where other users have read access by default)… What do you think about running the following command once as root from a security-misc Debian package maintainer script?

for folder_name in /home/* ; do
    chmod o-rwx "$folder_name"
done

This should probably also be done during account creating during boot.

This would help all users who haven’t had files leaked but who in future will have any non-root user being compromised since if others (i.e. non-group members) don’t have read access to /home/user then they also cannot read any files lets say /home/user/some-document even if it has default umask where others have read access?

1 Like

This was implemented but could be disabled if there is a good argument against it.

1 Like

Given our current implementation, still useful to set umask using sudo too?

This is what Qubes is using:

sudo cat /etc/sudoers.d/umask

# Sudo's defualt umask is 077 so set sane default of 022
Defaults umask = 0002
Defaults umask_override
1 Like

Sounds good. I don’t see any reason why this would be a bad thing.

Not sure. I never knew sudo could configure a umask. It might set the correct umask for sudo -u man bash and sudo sulogin so it may be useful.

1 Like

madaidan via Whonix Forum:

Sounds good. I don’t see any reason why this would be a bad thing.

There might be some systems using a webserver or something and then
pointing these to files in user home or so. An upgrade would break their
setup for them. Not a good enough reason to not do this since easily
fixed. A Whonix News warning about this could suffice.

1 Like
1 Like
2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]