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

[f33dm3bits]

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.

Users can change the permissions of their own homedir, what you could do as I mentioned before is make root the owner of all the homedirs. Then the group of the corresponding user of that homedir and set the homedirs with permission 770 and then the default umask 007(I think) that would make all the files and directories rw for the group. Then you could even have set the umask that world/other are world readable, since in this situation the homedir is only accessible by the user that the homedir is meant for.

So in short locking down the homedir making it so that the user can't change permissions on their own homedir, plus setting the default umask or fall users that files will be created with group rw for files(and rwx for directories) permissions. I think if you set it up this way it would prevent you from having to deal with worry about whether the display-manager is configured correctly to use the correct umask for gui applications. I always try to use the KISS principle, that way it's easier to remember and to setup.

 

[f33dm3bits]

That would then look like this.

tux@debian:~$ ls -l /home
total 4
drwxrwx--- 2 root tux 4096 Dec  6 17:03 tux

tux@debian:~$ chmod 775 /home/tux
chmod: changing permissions of '/home/tux': Operation not permitted

tux@debian:~$ cat /etc/profile.d/umask.sh
#Set default umask for all users
umask 007

tux@debian:~$ umask
0007

tux@debian:~$ pwd
/home/tux

tux@debian:~$ mkdir testdir
tux@debian:~$ touch testfile

tux@debian:~$ ls -l
total 4
drwxrwx--- 2 tux tux 4096 Dec  6 17:04 testdir
-rw-rw---- 1 tux tux    0 Dec  6 17:04 testfile

I think this setup is probably easier and more logical way of doing it than trying to configure the display-manager(or the xinit way) to use the default umask for gui apps and less work as well for the admin as well.

Also why would a user want to open their own homedir for other users, if files need to be shared a shared directory can be setup.

 

[Old Tom Bombadil]

I think the variable here might be gnome vs kde. I will check.

I used Cinnamon for both Fedora and Linux Mint, XFCE for Debian.

This below was offered as a "possible fix" for your problem. It's not what I did. It is still a fix for existing users, but new users would again receive the configured permissions from umask, login.defs, PAM, and anything else that bears on this problem. Sudo is needed here because it's changing all users' home folder permissions, not just ones own home folder.

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 *

Now I see what happened here with f33dm3bits, he came back again with more explanation, God bless him, and I had missed some posts.

I agree completely... Maarten is very proficient as a sysadmin. He has a much better understanding of what's going on than I do.

 

[motivation]

I tested Debian KDE, Debian Gnome, Fedora 37, Ubuntu 20.10, and Parrot Linux. The results are not good. Most users are forced to have world readable files, and they are accessible through cd to their home directory.

Specifically these distributions forced users to make world readable files on programs launched from the desktop (ignoring .profile, .xsession, .xinitrc, and .xprofile):

• Debian 11 Gnome
• Fedora 37
• Ubuntu 20.10
• Parrot Linux

Of note, Fedora 37 removed world permissions from the home directory file. Debian 11, Ubuntu, and Parrot leave the home directory open for world reading. More about this further below.(*)

Of those tested, only Debian 11 KDE respected a umask setting in .profile. So this is an answer to my question from the original post, comment #20 from f33dm3bits, though that comment deserved more explanation as we did not know if it was unusual, or common.

Parrot Linux refused to allow the user to login at all after .xsession, .xinitrc, and .xprofile were given a umask line, so it seemed to be reading those at login. Perhaps there is a magic incantation that would make it work.

I think the Debian 11 KDE was the only KDE desktop tested - so the answer to the original post might be 'any modern KDE machine, and modify .profile' -- I do not know.

SUSE had several install options among them a KDE option, but after a few hours of this ...


-------
(*) About the Fedora 37 approach, it is a bit of a kludge.

Directories do not impart permissions upon the files in them.

Files have their own permissions and they are set from the open command request flags combined with the umask when they are created.

Files are located by inode, not by path string.

There can be other links to get to files, and directories can be archived and restored, or mounted, on different systems that use the more usual 755 for home. Especially these days when many machines are virtual.

Perhaps a specific file system gives some guarantees about this. Perhaps Linux has passed a law about it. IDK

It is common in unix land to allow home directories to be readable so that users may share configuration files. If the user opens the directory for that reason -- then all the user readable files created by desktop programs will then become easily accessible by everyone on that Fedora system. (Arguably and improvement over other systems I suppose, where they are always accessible without any esoteric knowledge on how to get to them.)

On Fedora 37 if the user sets his or her umask there can be a mess of mixed file permissions, even made by the same program, depending if it was launched in a manner that ignored the .profile.

-----
As to the concept of installing an Xinit package .. firstly, that is outside of user land, but once done, yes, if users are setup to launch their own X servers they will be able to write .xinitrc etc. That is a little funny about linking the bash_profile to .xsessionrc. It seems that something in the xinit chain was sourcing bash_profile. I can now see why a site might want to go back to this.

----
oh gosh, we still have not heard from anyone who has already been around the block with this issue - perhaps in conversations like this one -- and what they did. I am guessing at the moment the simple answer is KDE. My answer is Debian KDE. Thanks for the engaging chat.

 

[motivation]

The idea that world readable files by default is somehow inherently a security problem, is unconvincing.

May I have an account on one of your production machines ;-)

, as an issue of responsibility for the user to set permissions.

Yes, the point being the user has not such option on many Linux installations. Anywhere the user would think to set a umask, it will be ignored by the desktop launcher. As we have worked through this, f33dm3bits did identify that Debian KDE looks at the ~/.profile. Note comment #44 for a review of some systems.

 

[motivation]

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.

It was wonderful chatting with you, and the others. It is so nice to be able to have such a discussion. I was so surprised by how long it went, that when I cam back to it, I missed a bunch of comments due to not considering the paging.

 

[motivation]

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!

Note comment #44. The directory locking is not present on most distros. It is an expedient that any user can employ. Still, unless my technical knowledge is outdated, not a very secure apporach, note the asterisk portion of #44. It isn't something I would want as a site policy myself. I prefer what Debian KDE has done, or installing the umask pam module.

 

[motivation]

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

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.

Note the (*) portion of comment 44. Though I see the conceptually it is nice to think about a file system as a tree with inheritance from parents, it does not work that way in many UNIX filesystems. Permissions are set on files when they are created, and according to the request of the creator and value of the umask. This is independent of where in a directory tree the file's inode might get listed, and that could be multiple places.

I like the other thing you touched on here. This conversation has me thinking about it. Should users be setting these permissions in the first place? It is complicated. It is nuanced, and users are ... well users, not administrators. ... So maybe the real answer is to setfacl, and turn off world readibility for the tree. The heck with sharing configuration files. If they want to do that, they can drop them into an email. In addition I could run a 'fix perms' script that makes the permissions like the facls just before doing an archive copy.

Many Linux machines are single user affairs. In the beginning one of the common arguments was trying to explain to users why they should not run as root! lol. Given the over use of sudo, I am not sure that debate has been settled. The advent of the container has been wonderful. I can let a user play admin on a virtual machine... though man that eats up the processors.

Again thank you for the conversation. I tried to follow, I lost you a bit when you went into lightDM might be why the Parrot system hiccuped when changing config files...

 

[motivation]

I used Cinnamon for both Fedora and Linux Mint, XFCE for Debian.

This below was offered as a "possible fix" for your problem. It's not what I

This is what I will recommend to users who have this problem. It is quick, gets the job done for normal people. There is a technical nuance buried in there (comment #44 the asterisk portion)

 

[osprey]

Motivation wrote:

, as an issue of responsibility for the user to set permissions.

Yes, the point being the user has not such option on many Linux installations.

Alas, I'm not actually aware of any linux system where a user is unable to manage the permissions of their files.

 

[Old Tom Bombadil]

It was wonderful chatting with you, and the others. It is so nice to be able to have such a discussion.

This is a good place to hangout. I appreciate that your question has made me scratch my head a bit... and realize that other distros are not so secured as I had thought. I don't run multi-user systems, so I've never had a need to consider this issue. It's been interesting and informative. Good luck!

 

[wizardfromoz]

G'day @motivation and welcome to linux.org

On

oh gosh, we still have not heard from anyone who has already been around the block with this issue - perhaps in conversations like this one -- and what they did.

Just be aware, with this snippet I use for some new Members

Just in case of any misapprehension on your part, we are not an official arm nor organ of Linux, just scored the dot org name - we are manned by volunteer staff who share a love of Linux and have varying skills in various departments.

That being so, we may only have a few sysadmins within our ranks, with Maarten being one of the most visible, bless him.

Do be aware, if you are not already, that there are likely over 500 Linux Distros available, and more in the wild. Add to that a plethora of DMs available for them, and the mathematical permutations and combinations resulting can make it extraordinarily daunting to find one config or setup that affords the functionality you are seeking.

I find this Thread to be an interesting read, and thank you for sharing with us.

Cheers

Chris Turner
wizardfromoz

 

[wizardfromoz]

BTW, on

• Ubuntu 20.10

I would take that out of the equation, as it reached End of Life, July 2021.

Cheers

Wizard

 

[f33dm3bits]

It is common in unix land to allow home directories to be readable so that users may share configuration files. If the user opens the directory for that reason -- then all the user readable files created by desktop programs will then become easily accessible by everyone on that Fedora system. (Arguably and improvement over other systems I suppose, where they are always accessible without any esoteric knowledge on how to get to them.)

That sounds old school or a just different way of doing it, I manage Linux systems for different medical research departments. Every user gets a homedir which only that user can access, if they have a shared application they all use it will run under a separate account where all the users have access to configurations, or they can get access to a shared directory, and a lot of people put their configurations in Gitlab as well and can share it that way too. So there are different ways of being able to share configuration files without the need to give someone else access to your homedir.

 

[f33dm3bits]

Note the (*) portion of comment 44. Though I see the conceptually it is nice to think about a file system as a tree with inheritance from parents, it does not work that way in many UNIX filesystems. Permissions are set on files when they are created, and according to the request of the creator and value of the umask. This is independent of where in a directory tree the file's inode might get listed, and that could be multiple places.

I like the other thing you touched on here. This conversation has me thinking about it. Should users be setting these permissions in the first place? It is complicated. It is nuanced, and users are ... well users, not administrators. ... So maybe the real answer is to setfacl, and turn off world readibility for the tree. The heck with sharing configuration files. If they want to do that, they can drop them into an email. In addition I could run a 'fix perms' script that makes the permissions like the facls just before doing an archive copy.

I just gave that as an idea because at some point in the thread you mentioned something about what if a user changes the permissions on their own homedir. The option of the user own each user's homedir and then the group of that users homedir the user themselves, would have to go hand in hand with the correct default umask. The option was also from preventing user to be able to enter each others homedir, if I were you I would just make all the users homedirs 700 and then give them a shared location to share files/configs, since it today's world you don't really want any users going through each others homedir even if it was setup correctly with permissions and umasks. That's just my two cents.

So it looks like you are going Debian with KDE and sddm as the solution of getting gui apps to respect the set umask? Any reason you wouldn't consider just to make homedirs 700 and give the users a different way to share configuration files?

Thanks for the chat as well and for sharing thoughts!

 

[osprey]

f33dm3bits wrote:

make all the users homedirs 700 and then give them a shared location to share files/configs

With that chmod, that's what NFS is for, a standard and time-honoured approach which makes the original issue of "visible files" somewhat neutralised, in practical terms.