is there any distro / dm that allows the user to uniformally change his or her umask?

[f33dm3bits]

With lightdm there is a configuration setting to run when starting the session, session-setup-script= but when using that doesn't seem to work. I then installed the package "xinit" and created a ~/.profile but it didn't work then. Instead when I created the following file.

tux@debian:~$ cat .xsessionrc
umask 006

Since your shell doesn't pick up ~/.xsessionrc I created a symlink so that same would go for my shell.

tux@debian:~$ ls -l .bash_profile
lrwxrwxrwx 1 tux tux 11 Dec  1 20:19 .bash_profile -> .xsessionrc

And that resulted in the following.

-rw-rw---- 1 tux tux    0 Dec  1 20:19 terminal.txt
-rw-rw---- 1 tux tux    0 Dec  1 20:20 gui_pluma.txt

So it works with lightdm as well.

 

[f33dm3bits]

That same trick with ~/.xsessionrc seems to have worked for gdm.

I also tried the ~/.xsessionrc file with lxdm and it works there as well.

-rw-rw---- 1 tux tux    0 Dec  1 20:37 terminal.txt
-rw-rw---- 1 tux tux    0 Dec  1 20:38 gui_pluma.txt

It seems installing the package "xinit" and using the the file ~/.xsessionrc are the best option for the user to have a custom umask under Debian. So depending on what you want to do it looks like it works on other displaymanagers as well.

However it seems to also depend on how your distribution has the displaymanager configured and if not by default depending on the displaymanager there are options to configure a startup script to load before your session loads and if not xinit works as well.

 

[osprey]

How can you like that? Every example shows world readable files. He is showing that the problem is there. Did I miss something?

There's no accounting for what some people like

 

[f33dm3bits]

How can you like that? Every example shows world readable files. He is showing that the problem is there. Did I miss something?

I was not trying to discredit you, it was a simple having misread something in your original post, forgive me for missing things sometimes English is not my first language and I tend to read over forum posts when I am also doing something(multi-tasking doesn't help me concentrate on one thing enough) else which doesn't help either. I was just sharing what I found from what I first understood from your post, now that you have clarified it and you pointed out that I missed something.

Just be glad people are interested in your post trying to think with you and sharing their ideas and thoughts. I was genuinely interested in your post because lately I've been ignoring most other posts because most posts here are the same but yours was different which I liked. It's not a contest who gets the most likes, it's about trying to understand and help figure something out or share ideas to come to a solution.

 

[osprey]

Motivation wrote:

In my opinion umask is an integral part of unix security, so it indicates an inattention to security details for a distro when a user umask is ignored, or even worse, partially ignored, with a different umask when a program comes from a menu than when it is invoked from a shell. This is my opinion other people might not be concerned when users are forced to make their files world readable to use programs from the GUI, or even think that is an advantage. I would be glad to hear the reasoning for that.

My understanding of the issue is this: when the user changes the umask in .bashrc or .profile, the files written from GUI programs don't observe the new umask, and this is of concern because users are "forced to make their files world readable".

Several observations now come to mind.

It seems Motivation wants a systemic solution for GUI programs to observe newly configured umasks that work for terminal programs but not for the GUI ones. What happens in the linux world usually, is that if there isn't a ready solution, one writes one, either a script or program or new configuration. And then that is often shared in the tradition of scientific collaboration. If one is dissatisfied with the defaults, they are alterable.

The idea that world readable files by default is somehow inherently a security problem, is unconvincing. Though it's apparently the default in many applications and systems to have world readable files, the capacity to restrict is available, hence it's not so much a security problem, as an issue of responsibility for the user to set permissions. The freedom to configure one's system is rather paramount in linux, but because that freedom exists, it leaves the field open to a greater possibility of messing things up. A user may wish for the system to take care of all of one's pet preferences, but that's not likely in a world like linux which is ever developing and endlessly changing. The evidence is that the modern linux user who wishes to move with the times is confronted with embracing uncertainty and fallibility to some degree. One can minimise these things by sticking with stable distributions, but not eliminate them because eventually that stable distribution will become vulnerable and obsolete.

It's appropriate to remind oneself from time to time that linux and any other Free and Open Source Software community project, comes without any warranty or promise of fitness for any particular purpose.

 

[Old Tom Bombadil]

One user was quite dismayed to find that everyone was able to read her journal.

Well, I will add to the confusion. I'm running standard Fedora 36.

1. I created user 'tom1' and user 'tom2'.
2. From the terminal, as user 'tom'... I cannot cd /home/tom1.
3. From the terminal, as user 'tom'... I cannot cd /home/tom2.

Likewise, user 'tom1' cannot access the home folder for 'tom' or 'tom2'.
Likewise, user 'tom2' cannot access the home folder for 'tom' or 'tom1'.

Switching to a GUI, using LibreOffice Writer, I cannot access the home folders of any other user to open any of their files.

So... "world readable" is not really readable by others on the system, except root. I don't see how your user's journal was accessible, except maybe due to belonging to a shared group or storing her journal outside of her home folder.

There is another mechanism in place (besides umask) that protects the user's files. I probably should know what that mechanism is, but it's not coming to me at the moment, and I've got other things to do. Good luck!

 

[f33dm3bits]

So... "world readable" is not really readable by others on the system, except root. I don't see how your user's journal was accessible, except maybe due to belonging to a shared group or storing her journal outside of her home folder.

I thought OP was using Debian or a Debian-based distribution. When I create a user on my Debian vm I see this.

root@debian:~# useradd -m f33dm3bits
root@debian:~# ls -l /home
total 8
drwxr-xr-x 2 f33dm3bits f33dm3bits 4096 Dec  3 15:48 f33dm3bits
drwxr-xr-x 2 tux        tux        4096 Nov 29 23:08 tux

And on my Fedora system I see this when having created a user.

[root@lilith ~]# ls -l /home
total 0
drwx------. 1 maarten maarten 1166 Dec  3 15:51 maarten
drwx------. 1 tux     tux      110 Dec  3 15:51 tux

So maybe that user's homedir had 755 permissions and because all the files in the users homedir were world readable that users was also able to read those files. I'm kind of getting the idea is the combination of those two.

 

[Old Tom Bombadil]

So my question to this board is: is there a linux distro or perhaps a dm that after a default install, users may set their umask value (setting it in ~/.profile would be conventional, but it does not matter what the file is called.) It has been a long time since 2016, so perhaps someone has integrated this.

I did a bare metal install of Debian 11.5 XFCE, and I see that it is not secured the same way as Fedora, just as @f33dm3bits described above. That's good to know! So I understand now how the user's journal could be read easily.

It seems that this below would lock down all the users home folders without messing with umask, but I'm not sure.

cd /home
sudo chmod 700 *

It may be that Fedora uses umask as the OP wants, but at least it seems more secure than Debian with a default installation, however it's done.

Cheers

 

[f33dm3bits]

It may be that Fedora uses umask as the OP wants, but at least it seems more secure than Debian with a default installation, however it's done.

Cheers

Fedora has "HOME_MODE" defined in "/etc/login.defs" and Debian doesn't. If you read man useradd in debian and search for "HOME_MODE" it says this.

HOME_MODE (number)
The mode for new home directories. If not specified, the UMASK is used to create the mode.

UMASK is set to 022 in login.defs, when I add HOME_MODE 0700 to to that file and then add a user on Debian then it looks like this.

root@debian:~# grep ^HOME_MODE /etc/login.defs
HOME_MODE        0700

root@debian:~# useradd -m f33dm3bits
root@debian:~# ls -l /home
total 8
drwx------ 2 f33dm3bits f33dm3bits 4096 Dec  4 08:50 f33dm3bits
drwxr-xr-x 2 tux        tux        4096 Nov 29 23:08 tux

And this same information is also mentioned in the mentioned /etc/login.defs that it might be better idea for privacy reason to change the UMASK value in that file for privacy reason.

# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.

root@debian:~# grep ^UMASK /etc/login.defs
UMASK        077

root@debian:~# useradd -m f33dm3bits
root@debian:~# ls -l /home
total 8
drwx------ 2 f33dm3bits f33dm3bits 4096 Dec  4 09:02 f33dm3bits
drwxr-xr-x 2 tux        tux        4096 Dec  4 08:55 tux

So I'm getting the strong idea that is a combination of the UMASK not being set in that file or HOME_MODE not being defined that caused another user being able to the enter the homedir of another user. Which then allowed that user to read the files of that user because they were world readable. The part about why graphical applications don't use the default umask set by a user is another story but which I got working with several different displaymanagers in my Debian vm.

 

[motivation]

So I'm getting the strong idea that is a combination of the UMASK not being set in that file or HOME_MODE not being defined that caused another user being able to the enter the homedir of another user. Which then allowed that user to read the files of that user because they were world readable. The part about why graphical applications don't use the default umask set by a user is another story but which I got working with several different displaymanagers in my Debian vm.

I gather this is a correct summary :

1. The current situation for users

The defaults in all the distros, for which the people following this thread are familiar, leave users with world readable files, and for programs launched from the GUI the users have no choice about this.

As most users use the GUI, and the distro defaults are by far the most common - we can expect that if we walk up to just about any Linux machine on the planet, if we have a user account on that machine, even if it is not privileged, we can read all the other user's files.

2. In contrast, users can control programs launched from a shell.

There are two workarounds for users who are willing to discipline themselves to use the command line.

For one, as Tom pointed out above, the user still owns his or her files, and may manually change their permissions. Those files will be world readable until they are changed.

The second is to set an appropriate umask in ~/.profile, log in again, **and then only launch programs from a shell command line**. If a user accidentally launches a program from the launcher, then the files created by it will be world readable, perhaps sitting right alongside others written by programs launched from the shell that are not.

3. An Administrator may force the desktop launcher to use a different umask.

An administrator can change the umask used by the desktop launcher to something else. (This was never in doubt, and was not the question.) Again, for this new umask the user will still have to live whatever the system sets, as all programs run from the desktop launcher will use it.

For administrators who want to force a different umask to be used by the desktop launcher, add the line "session optional pam_umask.so" to the file /etc/pam.d/common-session. Then change UMASK in /etc/login.defs to 0007, or something similar to so that files will not be world readable.

4. Another related topic has now been raised, that of home directory creation permissions, as explained above in this thread, an administrator may modify /etc/login.defs such that new home directories have permissions other than the default of 022.

If the admin takes away execute, than other users will not be able to cd to the directory, and if the admin takes away read, others will not be able to read the directory. But be careful to note! : new files do *not* inherit the permissions from the directory they are in. New files take their permissions from the umask - and the user has no control over the umask used by the desktop launcher. Note earlier points.

Also, because a user owns his or her home directory, he or she may changed the permissions on it after it is created.

This has a nuanced effect. Without other changes, files in the home directory will continue to be made world readable. It is just that other users will have difficulty getting to them. In the past it was still possible to find other user files through inodes found in the directory files. I do not know if today there are any guarantees that readable files in unreadable directories will be unreadable as a consequence of the other user not having a path through the directory tree for getting to them.

Again, this is tangential to the original question (how can a user set the umask for processes launched from the GUI - or rather if there is a distro that allows this). It might be a work around, though it begs questions. It certainly doesn't feel good to be making world readable files, and then despite the explicit permissions saying they are world readable, we say they are actually unreadable because these files can not be gotten to due to permissions on a directory in the path while trying to get to them.

-------
in brief:
1. users have no choice, files made by programs launched by the desktop launcher will be world readable (just try it ... jeeze).
2. and perhaps as evidenced by this thread, there is a lot of confusion among Linux admins as to how unix permissions work. And perhaps they may be forgiven, as the Linux setup is complex and nuanced.
3. despite all said in this thread, for all distros mentioned in this thread, #1 in this list remains a fact.

 

[f33dm3bits]

Again, this is tangential to the original question (how can a user set the umask for processes launched from the GUI - or rather if there is a distro that allows this). It might be a work around, though it begs questions. It certainly doesn't feel good to be making world readable files, and then despite the explicit permissions saying they are world readable, we say they are actually unreadable because these files can not be gotten to due to permissions on a directory in the path while trying to get to them.

I already gave you examples in posts #20-22 where I let the user set their own umask using different displaymanagers and two different methods.

 

[f33dm3bits]

If the admin takes away execute, than other users will not be able to cd to the directory, and if the admin takes away read, others will not be able to read the directory. But be careful to note! : new files do *not* inherit the permissions from the directory they are in. New files take their permissions from the umask - and the user has no control over the umask used by the desktop launcher. Note earlier points.

Also, because a user owns his or her home directory, he or she may changed the permissions on it after it is created.

You could make the home directory owned by root and by the group of the user that way if you as an admin set the homedir as 770, the user themselves won't be able to change, after that the the files within the users home directories will be created based on the default umask. Yes you would have to change the permissions of the already existing files and directories manually and you would have to make sure the default umask gives rw permissions for the group by default for all created files and rwx for the group for directories. For example like this.

root@debian:~# ls -l /home
drwxrwx--- 2 root f33dm3bits 4096 Dec  4 08:50 f33dm3bits

Again, this is tangential to the original question (how can a user set the umask for processes launched from the GUI - or rather if there is a distro that allows this). It might be a work around, though it begs questions. It certainly doesn't feel good to be making world readable files, and then despite the explicit permissions saying they are world readable, we say they are actually unreadable because these files can not be gotten to due to permissions on a directory in the path while trying to get to them.

I already gave you examples in posts #20-22 where I let the user set their own umask which worked with gui programs using different display-managers and two different methods. However you as an an admin will have set this up because it is not setup by default

 

[motivation]

I already gave you examples in posts #20-22 where I let the user set their own umask which worked with gui programs using different display-managers and two different methods. However you as an an admin will have set this up because it is not setup by default

It is me who must not be reading English, blurry eyed in the wee hours when looking down the permissions in the quotes swear I saw r--, but now see ---. Thank you for your patience - it is admirable and rare on the Internet.

I am spinning up a Debian plasma machine as you described in #20 to verify. (I already tried Parrot which I thought was that setup, but will get the original). What you describe in #22 is the way it used to work, and if they support it, that sure looks right.

bb in a few hours

 

[Old Tom Bombadil]

For one, as Tom pointed out above, the user still owns his or her files, and may manually change their permissions. Those files will be world readable until they are changed.

No, that's not what I said at all. I did not change any user permissions or umask settings. In Fedora, users could NOT access any files of another user in my testing, whether by GUI or command line.

While you are spinning up new VM's... try Fedora.

 

[f33dm3bits]

In Fedora, users could NOT access any files of another user in my testing, whether by GUI or command line.

In Fedora the homedirs are created with 700 by default. @motivation main issue is with gui programs not abiding to custom user set umasks. I think other users being able to enter other uses homedirs was another issue that was concluded from one user being able to enter another user's homedir. To then be able to read that user's journal because the gui apps don't respect the custom set umask by default making all files world readable, unless your display-manager is setup to do it or you set it up another way such as my second example that I tested using xinit.

 

[Old Tom Bombadil]

Yes, I may be misunderstanding OP's main concern (he wants users to set their own umask that will work). But his "current situation for users #1" says all distros have this behavior... that GUI launched programs will allow users to view other user's files. The default Fedora doesn't do that, from the brief testing that I did with it. Neither does Linux Mint.

If the goal is a better secured system, with less interaction needed by both the admin and the users, then Fedora seems to be a good choice. Setting a good umask seems to be an admin responsibility, rather than users, to me.

I did another test with Linux Mint yesterday. It uses HOME_MODE set to 0750 in /etc/login.defs. I changed that to 0700 (like Fedora) and rebooted, but the home folder permissions remained at 0750 for new users created after this change. It may be PAM settings (or other?) that has priority. Linux Mint also did not allow access between users (even with a GUI), but the 0750 setting should allow access (r-x) if members are of the same Group. I did not test that.

 

[f33dm3bits]

I did another test with Linux Mint yesterday. It uses HOME_MODE set to 0750 in /etc/login.defs. I changed that to 0700 (like Fedora) and rebooted, but the home folder permissions remained at 0750 for new users created after this change. It may be PAM settings (or other?) that has priority. Linux Mint also did not allow access between users (even with a GUI), but the 0750 setting should allow access (r-x) if members are of the same Group. I did not test that.

Changes in /etc/login.defs are only for users that are to still be created and is not effect by already existing users, that will have to manually be changed or using the pam umask module if it supports that.

Fedora has "HOME_MODE 0700" set by default in login.defs, Debian doesn't therefore when you create a user the homedir will have 755 permissions unless you change that in login.defs(which is the admins job to change that to needed/wanted permissions). In combination with GUI apps not respecting the default umask causes the end result other users being able to read each others files.

 

[Old Tom Bombadil]

Changes in /etc/login.defs are only for users that are to still be created

Yes, and I created a new user after changing to 0700... but the home folder did not give 0700 permissions. It still gave 0750 for the newly created user. So /etc/login.defs did not have an effect at all, in this case.

 

[f33dm3bits]

Yes, and I created a new user after changing to 0700... but the home folder did not give 0700 settings. It still gave 0750 for the newly created user. So /etc/login.defs did not have an effect at all, in this case.

Strange, I don't have time to try out Mint now but the settings used there will differ a bit per distribution. I think OP has something to work with now, I'm not going to overspend my time on this as I have got other things to do as well and I mostly only care about the distributions I use and I usually have a Debian vm installed as well.

 

[motivation]

No, that's not what I said at all. I did not change any user permissions or umask settings. In Fedora, users could NOT access any files of another user in my testing, whether by GUI or command line.

While you are spinning up new VM's... try Fedora.

Alright, I will bring up a Fedora in the mix. I think the variable here might be gnome vs kde. I will check.

I got the permissions change from this:

It seems that this below would lock down all the users home folders without messing with umask, but I'm not sure.

Code:
cd /home
sudo chmod 700 *

The sudo is not needed for a user to change his or her own home directory as a user owns his home directory. As per my note above, home directory permissions do not change, nor set the mask for, the files contained in the directory, so I had assumed you had intended to fix the files. Which would be something like:

> chmod -R o-rwx my_home

Now I see what happened here with f33dm3bits, he came back again with more explanation, God bless him, and I had missed some posts. There is a lot here that I need to read through now. You guys have done some nice work and have been persistent.