MX Linux Forum

Hi everyone,

I just installed MXlinux 19.4

I realize the users can read other users files ( /home/JDoe )

Is this specific to MXlinux ? who can I change this behavior by default. So any other created account will not have access to other users files.

Thanks.

you can change the ownership of the home folder so that only your user has access.

by default, users can see files but not edit them. this is not specific to MX.

Nope... time for some basic Linux courses methinks. You really will do yourself a huge disservice if you do not understand some Linux basics. Here are a few:
https://www.lifewire.com/beginners-guid ... ux-4090233
https://www.udemy.com/course/linux-basi ... beginners/
https://itsfoss.com/free-linux-training-courses/
https://web.njit.edu/~alexg/courses/cs3 ... torial.pdf

EDIT (Just found this online for free) ===> https://www.iiitd.edu.in/~amarjeet/File ... %209th.pdf

Read all the current MX documentation as well==>https://mxmanuals.s3.us-east-2.amazonaw ... 9/mxum.pdf

It's common to most desktop linux distributions. File permissions are controlled by your umask
https://geek-university.com/linux/set-t ... ted-files/

A users umask is usually set to 0022. If you set it to 0037 users sharing your group can read but not write to or execute it and others (except for root) have no permissions. 0077 lets just you access your newly made files.
To enable a new default umask, add the appropriate line to your ~/.bashrc file.
You can use the chmod to reset the permissions of your existing files.

Thank you @manyroads & @timkb4cq !
I know my question was basic but please refer to my signature :)

@SpongeBOB No problem at all. I sourced all the courses to help you find some sources of basic info. Learning is something I suggest/offer as an offer of assistance. We all benefit by acquiring new knowledge. And... we all have more to learn.

MX Linux could actually implement a much better solution, though, than users having to learn to manually change file and directory permissions.

The solution could allow to have both, private home directories and sharing directories for the individual users and groups.

It would be based on making Debian's default user's private group configuration work
(https://wiki.debian.org/UserPrivateGroups), and then creating proper directories with a script like this one:
https://salsa.debian.org/freedombox-tea ... ippets/518

For example, there is then only publicly readable, while $HOME points to to contain all the user's files by default (inaccessible to other users).

And group wise collaboration can occur in places like

Traditionally, Linux set the default system umask with a line in /etc/profile, i.e. Debian seems to have turned this function over to system.d, although apparently this can be overridden by the display manager and/or desktop. Searching the internet on this, there seems to be a bit of consternation about how users' can better control this basic function. Each user's .profile contains the following:

I notice that this is different in Manjaro (and maybe other Arch distros), the folders in /home have 'drwx------' permissions there. I can't really figure out which file regulates this, anyone knows?
edit: the answer is: /etc/login.defs, there you can change the UMASK value to 077 instead of 022 for more privacy
a quote from the file:

# 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.

I wanted to change my umask value to 077 but it took me hours of searching the Internet until I finally found the solution. And yes, there is a lot of conflicting information on the Internet about how to make a permanent and system-wide umask change (by "system-wide" I mean having all application follow the new umask value).

This is my experience.

I never had complete success with changing the umask value in ~/.bashrc - it only partially worked. By "partially worked" I mean that the change was permanent and it did create new files and directories using the new umask value like it should, BUT ONLY when using the Terminal to create them.

The problem was that it did not work was when files and directories were created outside the Terminal, for example in LibreOffice, FeatherPad, Thunar, browser, etc. because for some reason those applications used the default umask 022 value and not 077 that I wanted and that had been added to ~/.bashrc (Umask 022 gives 644 and 755 permissions for files/directories respectively while umask 077 will give 600/700 permissions for files/directories).

The solution for me was to edit "/etc/pam.d/common-session" and add the line in the below code window. (I use 077 because it will give "user" (me) read and write permissions for new files and read/write/execute for new directories, and nothing for "group" and "other" categories.) I added it to the end of the "common-session" file.
The above is the only thing that worked correctly. I had tried six different files from hours of Internet searching.

1. ~/.bashrc - "umask 077" worked permanently but only when creating files/directories in the Terminal. Outside applications used the default umask 022 value.

2. ~/.profile - "umask 077" never worked

3. /etc/bash.bashrc - "umask 077" never worked

4. /etc/profile - "umask 077" never worked

5. /etc/login.defs - "umask 077" never worked. I had changed line 151 umask value to 077 vice 022 and line 224 "USERGROUPS_ENAB yes" changed to "no". (There was conflicting information from different forums/websites on this working.)

6. /etc/pam.d/common-session - "umask 077" works fine - see solution paragraph above.

Edit: I logged out/in after editing a file. I had also tried combinations of the above, e.g. 1, 3, 5, and 4 together (all unsuccessfully). #6 is the only one that worked completely.

tony37 wrote: Mon Apr 26, 2021 5:16 pm I can't really figure out which file regulates this, anyone knows?
edit: the answer is: /etc/login.defs, there you can change the UMASK value

Most files mentioned are a legacy ways of setting an umask. For a system-wide default it now hast to be set only with pam_umask, and it is explained at:
https://wiki.debian.org/UserPrivateGrou ... ate_Groups

tony37 wrote: Mon Apr 26, 2021 5:16 pm I notice that this is different in Manjaro (and maybe other Arch distros), the folders in /home have 'drwx------' permissions there. I can't really figure out which file regulates this, anyone knows?
edit: the answer is: /etc/login.defs, there you can change the UMASK value to 077 instead of 022 for more privacy
a quote from the file:

# 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.

Fine for Manjaro and so forth, but that file never worked for me (my Post #10, paragraph 5). It didn't matter if "umask 077" was changed alone or with line 224 as described in that post. Neither worked, at least not for me in MX-19.3 (and I saw a good amount of information on the Internet about it working for others, albeit not in MX...).

Setting the umask alone, and even more though to a restrictive value that you were considerng, isn't very useful for multi-user sytems, though.

The linked wiki page and script explains how to take advantage of the fact that the user's actual permissions are a combination of the permissions of the whole directory path and the file.
Together with the fabulous Debian default for every user to be a member of their own private (single user) user group, and the "set-group-id" group directory feature in linux, controlling file access becomes really easy then.

All that users then need to do to collaborate on files is navigating and using the directory tree. (It makes the otherwise tedious need to manually adjust file permissions, obsolete.)

Strange, my first reply ended up in the forum above your question Stuart_M . Maybe I opened the editor just before your message appeared, or something.(ok, seems to be just the edit window that lists older posts below)

Anyway, concerning a proper solution for this forum thread:

With each user having their own user-private-group in Debian (and thus MX Linux), the umask should actually be *relaxed* to 002 (from the current 022).
It's much better to augment the /home directory tree with subirectories with proper permissions and adjust $HOME accordingly (like the brush-up-groupdirs script is doing).

A default umask of 002 is possible and preferable, because:
1) The default umask can grant the full and same permissions to the group as to the user, because only the user itself is member of its own default private-user-group.
2) The default umask can grant "others" the file read permissions, if the access to the file is properly restricted by the permissions of the directory path, by default, where needed (i.e. /home/JDoe/private etc.). And this allows public places like /home/JDoe/public_html to work as expected without having to manually adjust file permissions.
3) And as files created in group directories will get their group ownership assigned to the directory's group instead of to the creating user's private group (special-cased "set-user-id" dirs), the same default 002 umask is also able to assign the proper group permissions to the files in group directories.

In other words, putting Debian's default user-private-groups to good use, allows "managing file permissions" to become a non-issue for the users (while at the same time bringing privacy as well as super easy collaboration on shared files to all users).

Actually, the wiki says pam_umask supports a "usergroups" option to automatically only widen the default umask for users with a user-private-group. So, no need to statically set a widened 002 umask, to support a brushed-up /home data directory tree.

And with current upstream's pam_umask versions, it seems the "usergroups" option can even be made a default now: https://salsa.debian.org/vorlon/pam/-/merge_requests/3

Uh, just read that the new ubuntu release just indiscriminately closed down the home directories completely. instead of improving the /home filesystem usability, and to improve the default permission situation with it.

Could be a good opportunity to improve MX Linux by putting the user private groups to use.

Stuart_M wrote: Mon Apr 26, 2021 5:26 pm ... edit "/etc/pam.d/common-session" and add the line in the below code window...

Code: Select all

session optional pam_umask.so umask=077

@Stuart_M Thank you very much for your discovery ! it work nice !

I have tried also -> but it seem not working.. can we set the umask in symbolic format instead of octal ? Thanks.

SpongeBOB wrote: Fri Jun 11, 2021 5:00 am I have tried also ->

Code: Select all

session optional pam_umask.so umask=g=,o=

but it seem not working.. can we set the umask in symbolic format instead of octal ? Thanks.

I don't see how using the symbolic representation would be able to distinguish between a file and directory, which is what the octal numeric representation will do.

I have seen umask used citing the symbolic mode, but only when referenced to just files and never when dealing with both files and directories. For example, see https://www.computerhope.com/unix/uumask.htm and scroll down to the heading "So how does the umask actually work?".

That said, try removing the first equal sign and putting a space in its stead (followed by the "g"). I would be surprised if it works, but you've not nothing to lose by trying and see what happens. Or: If that still doesn't work, try putting "umask go=" in apostrophes or quotes.

If it does work, I would guess that all newly created files and directories would then have the same permissions, meaning all files would have the execute permission regardless of it being needed, since directories must have that permission in order to be accessed. That is not a problem per se, but giving the execute permission to all files is not something I would do.

Other than my above suggestions, I would be at a loss as to whether the symbolic mode is possible when using "umask" in this application.

I just tested what I said in my Post #19 and none of the two commands I suggested worked, with or without the apostrophes or quotes. So I'll say octal numerical representation is needed when using umask as suggested in my Post #10, e.g. "umask=xxx" where "x" equals 0-7, or a valid octal number.

For visitors reading this thread that do not know what a valid octal number should be, there is a lot of information available from an internet search of "umask", such as:

https://www.computerhope.com/unix/uumask.htm for the easier to read, and https://en.wikipedia.org/wiki/Umask for the more technical.

Thanks again @Stuart_M to have try ! So Octal it is.

Oh one more question related to permissions.

Is possible to create an umask that create file/folder without group permission ? (can we do that in Linux ?)

@SpongeBOB 077 gives you an “effective” permission of 700, so just the owner.

Is that what you are asking?

Edit: that’s rwx for the owner only