umask, file copy, file creation, directory creation - I'm confused, please help

[GhX6GZMB]

In a recent thread https://ubuntuforums.org/showthread.php?t=2442799 this issue was partially discussed.

But I'm confused.

I've manually set all my private directories and files in $HOME to block "other" completely using the chmod command with appropriate variables. This works 100%.

But when I create a new file, or copy from an outside source (eg, USB-stick), "other" always gets an r flag for those files.

How can I stop this permanently?

I've read up on the umask command, but there's no permanency in that alone. In which configuration file can I set the umask so it's automatic? Or is it a completely different parameter I'm looking for?

Thank You.

[TheFu]

In another thread the last few days, it was pointed out that either systemd or gnome has a huge bug https://bugs.launchpad.net/ubuntu/+s...d/+bug/1685754 mainly due to the fact that the Gnome session is started before reading our personalized startup files where a normal user should have control over their umask.

Seems to get the desired behavior is to modify the settings systemwide in the login.def file. The default in that file is:

UMASK           022

May want to look up the

USERGROUPS_ENAB yes

setting as well.

These are definitely bugs. They violate the expectation that users have control over their umask. The changes above would be workarounds for the bug. In theory, the bug was fixed in March 2021.

[scorp123]

But when I create a new file, or copy from an outside source (eg, USB-stick), "other" always gets an r flag for those files.

Does that even matter? Because if your $HOME directory /home/yourusername has its permissions set to "rwx --- ---" (aka "chmod 700") then it does not matter what permissions a file inside that directory gets... others would still not be able to access it because the "700" permissions on the home directory would prevent them from even getting there and reading anything.

[TheFu]

Does that even matter? Because if your $HOME directory /home/yourusername has its permissions set to "rwx --- ---" (aka "chmod 700") then it does not matter what permissions a file inside that directory gets... others would still not be able to access it because the "700" permissions on the home directory would prevent them from even getting there and reading anything.

Technically correct, but it would drive me nuts wondering whether I'd accidentally resent ~/ permissions.

umask should work across all user processes if set in the ~/.profile. Anything less is a bug.

[scorp123]

Anything less is a bug.

No argument there.

[Morbius1]

I've manually set all my private directories and files in $HOME to block "other" completely using the chmod command with appropriate variables.

More of an FYI but there was no need to remove "other" from every directory and file in $HOME. All you needed to do is issue a chmod 0770 on $HOME.

The file system is hierarchical so block it anywhere along the path and it blocks access to everything past it.

Ubuntu 21.04 changes the default permissions on a users home directory to 750 so users cannot see each others files. If a second user attempts it they get stopped:

smbuser@vub2104:~$ ls -al /home/tester
ls: cannot open directory '/home/tester': Permission denied

[GhX6GZMB]

Thank You for your answers.
I'm not looking for the radical 700 mode for my home directories. It's not as simple as that.
Rather, I like having user and group enabled, and controlling access through user/groups management. This fits best in my environment.

Also, the "700" scenario wouldn't work. Presently I have this:

macro@macro-pc:/home$ ls -la
tdrwxr-xr-x  6 root    root     4096 May 10 23:22 .
drwxr-xr-x 21 root    root     4096 Jun  5 22:09 ..
drwxr-x--x 15 abguest abguest  4096 Jun  5 21:42 abguest
drwx------  2 root    root    16384 May  4  2020 lost+found
drwxr-x--x 17 macro   macro    4096 Jun 12 22:36 macro
drwxr-x--x  9 root    root     4096 Jun 10 22:09 timeshiftotal 36

As you see, /home has the x flags set for $HOME. There are reasons for this.
An example $HOME directory looks like this:

macro@macro-pc:/home/abguest$ ls -la
total 676
drwxr-x--x 15 abguest abguest   4096 Jun  5 21:42 .
drwxr-xr-x  6 root    root      4096 May 10 23:22 ..
-rw-------  1 abguest abguest    143 Jun  3 01:07 .bash_history
-rw-r-----  1 abguest abguest    220 Feb 25  2020 .bash_logout
-rw-r-----  1 abguest abguest   3771 Feb 25  2020 .bashrc
drwxrwx---  8 abguest abguest   4096 Jun  3 01:06 .cache
drwxrwx--- 17 abguest abguest   4096 Oct  2  2020 .config
drwxrwx---  2 abguest abguest   4096 Jun  5 21:42 Desktop
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Documents
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Downloads
-rw-r--r--  1 abguest abguest 108191 Jan 14  2020 .face.icon
drwx------  3 abguest abguest   4096 May  9  2020 .gnupg
drwxrwx---  3 abguest abguest   4096 May  9  2020 .local
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Music
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Pictures
drwx------  3 abguest abguest   4096 May 13  2020 .pki
-rw-r-----  1 abguest abguest    807 Feb 25  2020 .profile
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Public
drwxr-x---  2 abguest abguest   4096 May 13 23:30 Templates
drwxr-x---  2 abguest abguest   4096 Apr 26 22:29 Videos
-rw-------  1 abguest abguest     53 Jun  5 21:42 .Xauthority
-rw-rw----  1 abguest abguest   9120 Oct 11  2020 .xscreensaver
-rw-------  1 abguest abguest 483913 Jun  5 21:44 .xsession-errors

The odd man out is .face.icon which needs r rights, as it is needed before logging in (SDDM).

Everything else under $HOME should have no rights for "other" at all.

My remaining question is: is /etc/login.defs the right place to change the umask value, or are there other files that need to be changed?

[GhX6GZMB]

OK, I've now tested this.
The desired result when creating new files or directories is achived by editing /etc/login.defs:

# 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.
#
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
ERASECHAR    0177
KILLCHAR    025
UMASK        027

and

# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# If set to yes, userdel will remove the user's group if it contains no
# more members, and useradd will create by default a group with the name
# of the user.
#
USERGROUPS_ENAB no

BUT!! this only works for newly created files and directories.
If I copy files from outside, like a USB-stick, the permissions are completely uncontrolled.

There must be an additional setting/filter somewhere. Please help!

[TheFu]

What file system is used? That's always relevant. If they have a native Linux/POSIX compliant file system, then the permissions should carry over. With FAT32/exFAT/NTFS, then all bets are off. You get what the mount options say.

umask is only for new files and only onto POSIX standard storage.

[GhX6GZMB]

What file system is used? That's always relevant. If they have a native Linux/POSIX compliant file system, then the permissions should carry over. With FAT32/exFAT/NTFS, then all bets are off. You get what the mount options say.

umask is only for new files and only onto POSIX standard storage.

I feared that answer.
External storage can be anything, but mostly files from FAT/NTFS systems. My hope was that it's possible to force permissions when copying from external sources. Why not? M$ files don't even have those attributes.
Another source is downloads from the Web. Resulting permissions are also no good.