In the past, I have always set umask at ~/.profile. I set a umask of 077 so my documents get a permission of 600 (rw-------). But setting this at ~/.profile no longer works in Ubuntu 17.04.
So as new documents get created in a gnome session on Ubuntu 17.04, where can I configure so that they get created with permission 600?
To set permissions for all directories and files that are created day-forward by any user:
New files will be 600. New directories will be 700.
/etc/pam.d/common-session directly, given that the value is primarily defined in /etc/login.defs (at least as of 18.04 - has that changed)?
May 10, 2019 at 15:24
.profile: "for setting the umask for ssh logins, install and configure the libpam-umask package"
Jul 14, 2019 at 2:11
tl; dr: Replace UMASK 022 by e.g. UMASK 027 in file /etc/login.defs but doesn't work 100%.
See the man pages (20.04) for info on this. There are several places where it can be set: I used /etc/pam.d/login or /etc/default/login in the past but stopped working so now I'm using /etc/login.defs which partially works.
The PAM module tries to get the umask value from the following places in the following order:
· umask= entry in the user's GECOS field
· umask= argument
· UMASK entry from /etc/login.defs (influenced by USERGROUPS_ENAB in /etc/login.defs)
· UMASK= entry from /etc/default/login
(...)
EXAMPLES
Add the following line to /etc/pam.d/login to set the user specific umask at login:
session optional pam_umask.so umask=0022
In file /etc/login.defs there is an entry UMASK 022 that can be replaced by, in my case, UMASK 027. Then reboot. This yields:
$ umask
0022
$ more /etc/login.defs | grep ^UMASK
UMASK 027
$ echo foo > terminal
NOTE: Open gedit from Dock and write file `dock`
Open gedit from Menu and write file `menu`
$ ls -l dock menu terminal
-rw-r--r-- 1 daniel daniel 4 nov 4 16:11 dock
-rw-rw---- 1 daniel daniel 4 nov 4 16:11 menu
-rw-r--r-- 1 daniel daniel 4 nov 4 16:11 terminal
$ umask
0007
$ more /etc/login.defs | grep ^UMASK
UMASK 027
$ ls -l foo bar
ls: cannot access 'foo': No such file or directory
ls: cannot access 'bar': No such file or directory
$ touch foo
$ echo hello > bar
$ ls -l foo bar
-rw-rw---- 1 daniel daniel 6 nov 4 17:20 bar
-rw-rw---- 1 daniel daniel 0 nov 4 17:20 foo
Note this file does not exist on my version of Ubuntu, in which case we can create it.
$ sudo sh -c "echo 'session optional pam_umask.so umask=0027' >> /etc/default/login"
$ more /etc/default/login
session optional pam_umask.so umask=0027
Now if we restart and ask for the umask in the terminal we still get 0022 (in the case of Ubuntu 18.04) and not the 0027 that was set. See Bug #1685754.
But if we open an application, for example the Text Editor, and save a file we'll notice the new umask affected permissions. Open it from the menu, not from the terminal as it seems to pick up the (bad) umask from the terminal.
UMASK value directly in the preexisting /etc/login.defs file (or does that work differently in 17.04)? Also, you mention /etc/pam.d/login in the text, but your command modifies /etc/default/login.
May 10, 2019 at 15:20
/etc/default/login or /etc/pam.d/login in the past and these seemed to somehow work for some time, but not anymore. I now did a new installation with Ubuntu 20.04 and the same issue come up, I'm now using /etc/login.defs. The man page states all of these configuration files affect permissions.
I have recently came across this on Ubuntu 20.04 TLS and found the solution.
$ man -k umask
$ man pam_umask
This will get us the location of manual pages that discuss umask - all information can be found there.
From /etc/pam.d/common-session:
The pam_umask module will set the umask according to the system default in /etc/login.defs and user settings.
This solves the problem of different umask settings with different shells, display managers, remote sessions etc.
From PAM_UMASK(8):
pam_umask is a PAM module to set the file mode creation mask of the current environment. The PAM module tries to get the umask value from the following places in the following order:
umask= entry in the user's GECOS field
umask= argument UMASK entry
from /etc/login.defs (influenced by USERGROUPS_ENAB in /etc/login.defs)
UMASK= entry from /etc/default/login
Notice the text in the brackets: influenced by USERGROUPS_ENAB in /etc/login.defs.
What is USERGROUPS_ENAB?
From /etc/login.defs:
If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value for private user groups, i. e. the uid is the same as gid, and username is the same as the primary group name: for these, the user permissions will be used as group permissions, e. g. 022 will become 002.
In not specified, the permission mask (umask) is initialized to 022.
You can now run this:
$ sudo nl /etc/login.defs | grep USERGROUPS_ENAB
to double-check if you have USERGROUPS_ENAB set to "yes", if it's uncommented (default), and on which line of the document can you find it.
Therefore, when you change the default "UMASK 022" to "UMASK 027", if USERGROUPS_ENAB is set to "yes", you will see that your umask has been set to 007 (not 027) - as it ignores the 2nd position (group permissions).
The solution to this is simple: uncomment the line where "USERGROUPS_ENAB" is set to "yes". If you have changed umask value to "UMASK 027", you will have umask set to 027 after the reboot.
You can verify this by running this in your shell.
$ umask
To summarize, the only config file that matters is /etc/login.defs.
Set your umask to desired value and make sure to uncomment USERGROUPS_ENAB line to change group permissions as well.
Hope this helps.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
That's literally what your ~/.profile says. Did you relogin once changed? It should work fine.
Also:
This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login exists.
Actually confirmed the issue on a freshly installed ubuntu 17.04. Even fully updating still causes this issue to arise and even ~/.bash_profileis ignored, there seems to be an issue with the command interpreter not reading those files after login.
You can use ~/.bashrc for now, which still works fine and is read during login.
So after digging a little into it, it seems bash is not run by default with the --login anymore which means it doesn't read the ~/.profile. Starting a new bash with the umask in ~/.profile with bash --login sets the umask correctly starting a bash without it though ignores the ~/.profile. Not sure what was changed but this seems like a bug to me unless it was intentionally changed.
~/.bashrc for now this is still read during startup.
bash -login? How do I implement this exactly? Or is this unfixable until a bug is fixed?
If you're using GDM, it doesn't read ~/.profile like LightDM does. And the terminal normally opens a non-login shell. The net effect is that ~/.profile is not loaded at all when you open a terminal after logging in using GDM.
Either:
~/.bashrc, orOn Ubuntu 18.04.3 I have tried to create /etc/default/login with session optional pam_umask.so umask=0027 as Daniel says but not worked for me, instead I have changed the umask in /etc/login.defs and it worked.
I have changed umask value in 002 and now all the users create files with full permission also for their own group.
I have the workaround at least on Fedora 31:
sudo vi /etc/profile.d/umask.sh
umask <your_umask>
sudo vi /etc/login.defs
UMASK <your_umask>
sudo vi /usr/local/bin/systemd-user
/usr/lib/systemd/systemd --user
sudo chmod a+x /usr/local/bin/systemd-user
sudo vi /usr/lib/systemd/system/[email protected]
ExecStart=-/usr/local/bin/systemd-user
