I’d asked off-handedly about this (“How do I change system-wide default umask?”) as an aside on a different topic, and the answer I was given was "set umask in ‘/etc/profile’ ". But that’s wrong, because “/etc/profile” is only run by login shells and most shells aren’t login, and GUI apps ignore it completely. But I finally found a solution on a Fedora forum:
Become root.
Edit file “/etc/login.defs” and change UMASK to desired value.
Edit file “/etc/pam.d/system-auth” and add this line at the bottom: “session optional pam_umask.so usergroups”
Restart machine, and log back in as normal user.
System-wide umask will now be whatever you just set. (I use “002”, because all my data files are property of my main user “aragorn”, but I have an alternate administrative user “gandalf” who is also a member of aragorn’s group, and I want him to also have full control, which the default umask 022 would deny.)
Now, I don’t pretend to understand how that solution works, and I don’t know if that’s the only way or the best way; but for me it’s working. If I “touch” a not-yet-existing file it becomes rw-rw-r–. If I mkdir a new dir it becomes drwxrwxr-x. If I “create new folder” in Dolphin, it’s drwxrwxr-x.
Query: are there other or better ways of doing ths?
Setting the umask value via /etc/profile does no longer work for KDE / Plasma sessions because these are started as systemd user units. umask - ArchWiki
Well, setting umask in “/etc/profile” will “work” for files created from the command line in login shells (say, if you set your “shell” for Konsole to “bash -l” then launch a Konsole; or, if you type “su -l”). But in all other contexts, as far as I know, “/etc/profile” is ignored.
As for systemd, I’m curious: you seem to be implying that that’s a DE-dependent thing. So, if I launch a Manjaro session in some other DE – say, Gnome3 or Budgie – could that session theoretically be a non-systemd session? Or is systemd independent of DE?
As an amusing aside, it appears that “systemd” owes its name to the concept “System D”, popularized by Anthony Bourdain, Nicolas Freeling, and George Orwell, all of whom got it from French slang terms meaning “able to quickly find innovative solutions to emergency situations”. The Wikipedia article on “System D” recommends reading the book “The Kitchen” by Nicolas Freeling for more on this concept, and lists “systemd” as a related topic.
That will work just fine… as long as you use CLI only, and make sure that all shells are log-in shells. Otherwise, everything defaults to 022 because that’s what’s hard-coded into systemd, as I understand it.
Interesting. I suppose in a way that makes sense, because root stuff include a lot of executables, including nearly everything in “/usr/bin” which everyone needs to be able to execute.
In my case, I put 002 in “/etc/login.defs” because I do a lot of programming, so my own binaries and scripts need to be executable. Also, I have a second admin user (gandalf) in my main user (aragorn) group, and I want gandalf to have the same rights over aragorn’s stuff as aragorn has. Hence 002 instead of 022 or 077.
I think I’ll put “umask 022” in “/root/.bashrc”, though.
I wonder if the 002 I put in “/etc/login.defs” applies to files installed by pacman/pamac? I hope not. I suppose the only way to find out is install something and look at its file in “/usr/bin”. :::installs gnumeric::: Nope, “/usr/bin/gnumeric-1.12.55” is 022 (perms 755), not 002 (775). Good, “/etc/login.defs” doesn’t mess with program installation.
No, it also works for every GUI application, including your desktop environment, because those are all started as child processes of your login, and therefore they inherit your initial umask.
I ran some experiments, and they suggest otherwise. On a typical up-to-date (2023-03-12) Manjaro-Plasma system, I ran these experiments:
Experiment 1: Leaving the above changes to “/etc/login.defs” and “/etc/pam.d/system-auth” in-place, I put “umask 077” at the bottom of “/etc/profile” and “umask 007”, restarted system, launched Dolphin, right-clicked home, “create new text file”, “test.txt”. Permissions: -rw-rw-r-- (umask 002). The “.bashrc” umask would have given -rw------- and the “profile” umask would have given -rw-rw----
Experiment 2: I commented-out the umask-related lines in “/etc/login.defs” and “/etc/pam.d/system-auth”, left profile umask 077 and .bashrc umask 007 and restarted. Dolphin, erase old test file, make another “test.txt”, perms = -rw-r–r-- (umask 022, which is the hard-coded default in systemd). I also verifed that a test file made in a root login session “su -l” in BASH is -rw------- (umask 077) and a test file made by my regular user, aragorn, in Bash is -rw-rw---- (umask 007)
Bottom line: it appears that in current Manjaro Linux, GUI apps take their umask from systemd hard-coded default 022, which can apparently be altered only by editing “/etc/login.defs” and “/etc/pam.d/system-auth”. The file “/etc/profile” affects only login shells and CLI operations done by such shells. The file “/home/username/.bashrc” affects only non-login shells and CLI operations done by such shells.
I think you’re thinking of non-systemd systems, where apparently “/etc/profile” has more authority.
Interesting. I’m not clear on exactly what that line does, but it apparently is supposed to force the entire system to take its umask from “/etc/login.defs”. I may take it out and see what changes.
Good point, as that field is labeled “Required?” and all the lines have either “required” or “optional” in that field.
As for what happens when I take that line out of “/etc/pam.d/system-auth” on my work Manjaro-Plasma computer, BASH on Konsole obeys “/etc/login.defs” (umask=002), but Dolphin now reverts to systemd default (umask=022). So I’m gonna put it back in, because I like my secondary-admin acct to have write access to my main acct.
I’ve just tested that here with an empty file created by Dolphin, but the file had 600 permissions, as is to be expected with my umask of 077, and yet I don’t have that line in /etc/pam.d/system-auth.
It appears that I was wrong, and therefore I owe @robbie-hatley an apology for my skepticism.
I have done the test again with KWrite after noticing that certain (but not all) files and directories under my home directory were still readable to group and others, in spite of my umask of 077. And sure enough, the new file was created with 644 permissions.
