Users can read other users files !? [Solved]

[Sterling]

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

[Stuart_M]

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

[Sterling]

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

[Sterling]

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.

[Sterling]

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

[Sterling]

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

[Sterling]

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.

[SpongeBOB]

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

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.

[Stuart_M]

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.

Code: Select all

session optional pam_umask.so umask g=,o=

Or:

Code: Select all

session optional pam_umask.so umask go=

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.

[Stuart_M]

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.