Help with umask settings

Hi all,

I’d like to know where to set the umask. I don’t if this is standard, but I get 0002… so each new dir/file gets 775/664.

When looking in files where it might get set/change the default umask. I see 022.

$ grep -i ^umask /etc/login.defs  /etc/init.d/functions
/etc/login.defs:UMASK		022
/etc/init.d/functions:umask 022
$ umask
0002

So, creating dir/file in my home folder gives me 775/664, and when using sudo 755/644.

I guess I could add umask 022 to .profile, but thought it would be better to ask here for the correct way to do it.

· Eric

Red Hat has in /etc/bashrc:

    # By default, we want umask to get set. This sets it for non-login shell.
    # Current threshold for system reserved uid/gids is 200
    # You could check uidgid reservation validity in
    # /usr/share/doc/setup-*/uidgid file
    if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
       umask 002
    else
       umask 022
    fi

The rationale for this is that if you create files in shared directory, then group sharing that
directory should gain write access. However, the primary group of account is “private” and no other account is a member. Hence one needs something extra, like group sticky bit set on the shared directory in order to have the shared group set on the files.

The ~/.bash_profile sources ~/.bashrc and ~/.bashrc sources /etc/bashrc, so at end of ~/.bashrc would be the logical place for single user to modify the umask.

Thank jlehtone,

Ok, I found it in /etc/profile. :+1:

So one could maybe do something like:

if [ $UID -gt 999 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 022
else
    if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
        umask 002
    else
        umask 022
    fi
fi

That would give uid 200-999 → 002, and me (1000) and above 022.

 

If I would use Samba (not very likely though), you can set that in the prefs file (like masking), right? I don’t know what else I would share, unless it’s some sort of web service folder I can chmod manually for its spec cause.

· Eric

Oh, you have Rocky 8. In el8 the umask is indeed set in both /etc/profile and /etc/bashrc.
In el9 it was reduced into only /etc/bashrc as to set same thing in both is redundant.

[root@el8 ~]# grep umask /etc/profile /etc/bashrc
/etc/profile:# By default, we want umask to get set. This sets it for login shell
/etc/profile:    umask 002
/etc/profile:    umask 022
/etc/bashrc:    # By default, we want umask to get set. This sets it for non-login shell.
/etc/bashrc:       umask 002
/etc/bashrc:       umask 022

You don’t want to edit those files, because they do come from RPMs. If the packages are ever updated … are those files flagged as “config” and keep your changes, or just overwrite?

Both files seem to source /etc/profile.d/*.sh at the end. You can add file /etc/profile.d/eric.sh with:

umask 022

That should do the trick.

Overall, why is 002 a problem for you?

Aah… Thank you!! I must have missed it i bashrc.

Yes, you’re right - they can get updated on any update, so that was a much nicer/better way. Thank you so much! :+1:

 

I don’t know… Not a real problem, I guess. Maybe feels a little too generous? …cmp to standard 755/644. I know over the years I’ve always been annoyed by *fat disks plugged in, and everything copied went 777. And on my old Mac - for some reason when dragging a picture from Firefox to the desktop, or into a folder, they got 750/640. So, when you later pushed that image and forgot to fix it first (because everything looked ok in the testbed) - it didn’t display on the website. (guess I’'ve developed some sort of “permission-OCD” from that. ^_^) For mounting (*fat) usb-disks/sticks now, I’ll always check first, and if it’s a disk I use regularly, you can put 022 it in fstab. I haven’t checked yet in Rocky, how it behaves with *fat disks. Maybe it’s already set in some auto_fs file?

I guess it just feels better to origin from standard, and make adjustments when needed.

· Eric

Yes, but RHEL default is also that when user X creates a file, then the group (that has write access) of file is also X and the group has only one user as member: the X. In other words, other accounts do not
gain write access to those files.

If you change the primary group of user X into Y, then X gets umask 022.

When you push content to server, you probably should fix the owner/group/perms anyway.
That is just good practice, not OCD.

The *fat (and NTFS and some NAS filesystoms) are a whole different story.
All filesystems do not store posix permission attributes (or extended, or ACL).
The posix attributes that you see are created (mapped) on the fly from whatever the filesystem has
and as you chmod a mapping from posix to filesystem’s attributes occurs (as much as it can).

Yes, that makes better sense to change it like that, intead of an xtra file. And based on the code (user && uid = gid) it would escape the mask. I think I’ll go with that. :+1:

That actually reminds a little of OS X/macOS. Where a user is “username:staff” (501:20) and root is “root:wheel” (0:0). And that’s one of the things I always been wondering about - simce I’ve used both (Linux, osx) - why Linux systems have this username::username/root:root pattern as default. Never dived into it that much. Appearently it works for both, and just different choice of design I guess.

· Eric

If you think the Rocky 8.x default is wrong, you need to clearly state why, and how it could be improved. The main “annoyance” is that root is treated differently to standard user, meaning you get prompts trying to overwrite files and the like.

After some thinking I decided to go back to the file solution instead. Couldn’t find a suitable group to use, and started to think about what affect that might could have. And I didn’t just want make up a new one, just because… So, the file will keep everything as default as possible - any user above id200+ added through a program or service install will get the default, and accounts added by me (id1000+) will get from the file. I’ll put it n a spoiler here, in case someone else want/need it.

login_umask_1000-plus.sh
# umask initialization script (sh)
#
# /etc/profile.d/login_umask_1000-plus.sh
#
# umask 002:    775/664
# umask 022:    755/644
#
# - - -
#
# Set umask to 022 for users with uid/gid 1000 and over, to get standard
# file permissions. By default, users with uid/gid 200 and over get umask 002
#

if [ $UID -gt 999 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 022
fi

· Eric

In this case (about the umask)… Yes, I think I do. If I can get get some time and think of a proper answer, I’ll get back. Should I post it here, or send it somewhere?

But, that would just be my opinion. If you’re thinking about listening in on this, and thinking maybe the default umask should be changed. Perhaps a wider/deeper survey in the forum/community is better. Poll, discussion thread, etc.

 

No, not an annoyance. That’s how it should be. Root is root.

/* Only thing I wrote about annoyance was about old *fat disks, and how they mess up the perms with all being 777. */

· Eric

Yeah, fat and ntfs are a different ballgame - something from Windows, so annoying :slight_smile:

But otherwise, I don’t think that there is a major problem with the umask, or even the rights to directories/files - default on Linux from what I always remember of at least 20 years is username:username - BSD/Unix is most likely difference, hence what you saw on a Mac. That doesn’t mean Linux should be BSD though, or that BSD should be Linux and do username:username. That’s almost like expecting BSD or Linux to assume the same rights that Windows gives to files/directories.

Copying files should later have the appropriate rights assigned manually, be it assigning www-data or apache as the user/group with access to the files to be able to read or read/write. It should never be a case of copy and forget, and assume that the rights have been automatically set correctly - especially when across filesystems, or even from user home directories to a www directory for example. I expect there are commands that you can use that do not copy the rights along with the files - rsync for example will do that unless you use a parameter to preserve those permissions during the copy.

I expect the umask has been set for 90% of users - maybe higher or lower percentage. Other users have different requirements and can easily change it themselves. Forcing the majority of users, to use a umask that fits a minority though is not the right way to go about it. Discussions of course can be had, however, it would require the change to be introduced in RHEL, since Rocky is 1:1 to RHEL. So whatever RHEL has, Rocky has. There is obviously a reason why it is set as it is - most likely for the majority of cases it’s a good enough umask, restrictive, but not too restrictive which could be more problematic.

Yes, very. And even if you can mount it with mount options or using some auto_fs settings - still a lot of xtra stuff, just to get it to some sort of normal’ish usage. :slight_smile:

What will be very interesting now (haven’t followed it too much) is the new improved native Linux support for ExFat in the kernel (6.1+ ?). Will it also include som kind of handling permission, etc? So it shows up “normal” in Linux. Haven’t seen or tried yet, but that would be great if they figured that out. :+1: Then there would be a format that actually could be (somewhat) useful across platforms.

 

That’s why I chose to go with the file solution instead, to not mess with the groups or anything. The groups are fine, really. I just made a reflection to how others do.

But, like I said i post #5… The umask is maybe not a real problem, maybe just a bit generous. And I think using standard 755/644 (022) is better. At least for the “normal” user (ie. id1000+).

 

Yes, I can agree on that, and I buy in on the “sharing” perpective in the beginning of this thread. But, is really a sharing enviroment the default usage for 90%? I guess in a bigger corporated infrastructure like an office/business environment where everything maybe has a centralized management. But, for the normal user, you, me, and as a webserver. I can’t think of any situation where I would need other permissions, unless I decide to share a folder, or setup a server where some folders need altered permissions (but most of those things are usually taken care of by the install itself). I think it would be easier to start off with standard permissions, and then make changes based upon needs. If I’d need a shared folder - I setup one up, and that one can have the richer permissions.

And that’s why I didn’t set 022 for all, and keeping the default umask for whatever services that will be installed, with their own uid/gid. Just for the self-added users (id1000+). I guess it’s a “meeting halfways”-way. :slight_smile: So, I guess that is what I think should be the default - and it’s not too restrictive either. You don’t share your whole home folder, do you? Isn’t that what XDG_PUBLICSHARE_DIR is made for?

· Eric

That is most likely the rationale behind the umask that is set (at least on) RHEL systems.

You have your account ‘eric’ and have your files under ~eric.
The group ‘eric’ can write there too, but since user ‘eric’ is the only member of that group,
it does not matter whether there are other users or not; your files are safe even with 002.

If you do have to write to outside ~eric, then you have to do something extra anyway.


Lets add another user, ‘rico’. The ‘rico’ has files in ~rico that you can’t write.

Now, lets add directory /group/common, group ‘common’ and add both users to group ‘common’.
Furthermore,

chgrp common /group/common
chmod 2770 /group/common

Now both ‘eric’ and ‘rico’ can write to /group/common.
The group sticky bit sets group of every created file to be ‘common’.

If both of you have umask 022, then you have to explicitly chmod g+w for everything you add so that both can modify the added files.
If both have umask 002, then you don’t have to do that; the default makes it so. (There are still actions that can lead to the need to “fix perms”.)


I do know (Linux) systems (with config probably inherited from Unix) where each user belongs only to group that indicates affiliation. Rather than having

eric : eric common
rico : rico common

one has eric:common and rico:common or perhaps
eric:engineering and rico:marketing if the users are in different departments.
Note how RHEL’s default sets umask 022 for both. There can be many members in ‘engineering’, who all need write access to the engineering project data. The 022 becomes inconvenient.


You are free to set the default that minimizes needs for fixes in your environment.


PS. The if [ $UID -gt 199 ] is debatable. /etc/login.defs has:

#
# Min/max values for automatic uid selection in useradd(8)
#
UID_MIN                  1000
UID_MAX                 60000
# System accounts
SYS_UID_MIN               201
SYS_UID_MAX               999
# Extra per user uids
SUB_UID_MIN		   100000
SUB_UID_MAX		600100000
SUB_UID_COUNT		    65536
  • The 0–200 are reserved for system accounts that some packages explicitly create.
  • The 201–999 are reserved for system accounts that some packages and admin request.
  • The 1000-- are regular accounts.

Why should some system accounts have different umask than other system accounts?
They are all less likely to “share”, aren’t they?

1 Like

Thanks a for a good user example. :+1:

 

Yes, I also found that a bit off. But, I kept it that way since it was designed that way. I agree with you, so based on your example above - perhaps 002 is only/best suited for id1000+ (regular users).

But what’s the use case, does this mean like a dual boot computer where windows writes to an ExFat partition and then linux reads from it, or maybe a USB stick, but either way, UDF filesystem is better than ExFat.

Why is it better? UDF replace ISO9660 for usage on optical media - a place where FAT, NTFS, ext2/3/4, btrfs, xfs, etc are not used. Not really an ideal comparison. UDF wouldn’t be used on USB sticks or internal/external disks either since it’s pretty much purely for optical storage (DVD)

It’s been in there since (5.4|5.7), but I saw a post somewhere about new improvments now. Not sure, but it could be this one or this one I saw.

Yes, I assume you can use it the way you want it, but I think the main use is with ext disks, USB-sticks, SD-cards, etc. Since it’s “native”/non-fuse now, there’s no need for xtras. I’m most curious about if they’ve also managed to add som kind of perms nativly (in Linux) for exFAT, so it won’t show up as the other Windows fs’s. Eg like vfat can do: “The default is the umask of current process.” …»

UDF… Isn’t that an fs for ISO’s? Like when you burn a cd/dvd or something. I’m not too familiar with that one.

// A bit off topic, but anyway…

I got a little curious about the idea of using UDF, and wanted to test it. So, I made myself a small image file I now have in my home folder.

Like this…
$ fallocate -l 500M udf.img
$ sudo gdisk udf.img
// gdisk, 1 partition, all defaults,
// and copied the start/end sector: 2048, 1023966

$ losetup --offset $((512*2048)) --sizelimit $((512*1023966)) --show --find udf.img
$ sudo dnf in udftools
$ sudo mkudffs --utf8 --label="UDF test" /dev/loop0
$ sudo losetup -d /dev/loop0
$ mkdir udf.d
$ sudo mount -t udf -o offset=1048576,umask=0022,gid=1000,uid=1000 udf.img

Perhaps the wrong way to do it? Everything looks ok, and it seems to work like normal. But, how can I test it better. I have an ExFat usb stick (I think). I was thinking if there are tests one can do to compare? Or is the img file too small, and I’d need a bigger size, &/or maybe need to be on an actual media (like a usb stick)?

· Eric

I think UDF filesystem is misunderstood. Firstly FOSS; it’s the most free and open, and most cross-platform filesystem you can get. It can be used on optical media, but also on disk partitions and USB style removable. It can also be used as a full disk volume, without a partition table, and can be used for booting.

Copy some files from Mac that have ACLs and resource forks, then some files from NTFS that have named streams, then some files from linux that have selinux contexts. How well does ExFAT preserve those attributes? Then move on to hard links, sparse files, meta data mirroring and clustering, ExFAT is in the toilet before even getting this far…

1 Like

Thanks! :+1:

Yes, being FOSS, and a non-Windows FS, is what also interested me. :slight_smile:

Without partition table? When I made my dummy example. I used gdisk to create the partition, and then mkudffs when formatting it to UDF… I think it was on one of the first lines in the out put it mentioned something about writing MBR (which got me a bit worried, since I already did that with gdisk). So, how do you partition your drives?

The laptop I’m using now has a smartcard reader and can read an xd-card which I have a small one I thought I ould use as a test. Can I use the same command to format that one as in my dummy example, or should I add something more (was a lot of options in the manual)? I went with all deafult and only set the label and utf8).

 

That sounds like a great way to test it. Yes, I agree - ExFat is prob in the rear view on that. I don’t know about the NTFS part though. Don’t have anything here NTFS (and “named streams”?). But, I have old Mac files with resource forks, and of course all the Linux files (w. context).

I had this idea (still have) to install a system with LUKS and /boot on a removable stilck. So, I bought 2 identical 8G sticks (1 for backup), and the plan was to partition them with a bios partition, /boot partition and then also an ExFat - so I could also use it as a storage drive. Sounds like UDF would be a better option there, since it would incllude my old Macs and my Llinux computers - and if I’d need to bring some file(s) to a Windows computer.