Linux Permissions – Downsides of umask 077

linuxpermissionsumask

What are the cons, for having a restrictive umask of 077? A lot of distros (I believe all, except Red Hat? ) have a default umask of 022, configured in /etc/profile. This seems way too insecure for a non-desktop system, which multiple users are accessing, and security is of concern.

On a related note, on Ubuntu, the users' home directories are also created with 755 permissions, and the installer states that this is for making it easier for users to share files. Assuming that users' are comfortable setting permissions by hand to make files shared, this is not a problem.

What other downsides are there?

Best Answer

022 makes things convenient. 077 makes things less convenient, but depending on the circumstances and usage profile, it might not be any less convenient than having to use sudo.

I would argue that, like sudo, the actual, measurable security benefit you gain from this is negligible compared to the level of pain you inflict on yourself and your users. As a consultant, I have been scorned for my views on sudo and challenged to break numerous sudo setups, and I have yet to take more than 15 seconds to do so. Your call.

Knowing about umask is good, but it's just a single Corn Flake in the "complete breakfast". Maybe you should be asking yourself "Before I go mucking with default configs, the consistency of which will need to be maintained across installs, and which will need to be documented and justified to people who aren't dim-witted, what's this gonna buy me?"

Umask is also a bash built-in that is settable by individual users in their shell initialization files (~/.bash*), so you're not really able to easily enforce the umask. It's just a default. In other words, it's not buying you much.

Related Solutions

Why is the default umask value for useradd in openSUSE set to 022

Answering the question in your subject: OpenSuSE uses the traditional Unix umask setting, instead of the Debian-inspired one adopted by some other Linux distributions.

Editing /etc/login.defs should be sufficient to change it; this will not affect users currently logged in, nor is there any way for you to force such a change to programs that are currently running. It will also not affect users who have overridden it in their ~/.profile (or .bash_profile, .login, etc. as per their shell).

useradd is not involved with this; it is a per-process setting and the default is set during login (hence login.defs and not /etc/default/useradd).

Linux – Setting umask of libvirt/virt-manager for proper permissions in a directory shared by host and guest

I realize this is a very old post but I just recently solved this exact problem by submitting patches to libvirt. Starting in libvirt v6.10, you'll be able to specify the "fmode" and "dmode" options on 9pfs shares which control the default host permissions on files and directories, respectively.

If you can't run v6.10, I found a workaround using the qemu:commandline feature of libvirt's XML domain to pass the raw QEMU flags. I wrote a blog post about how to do this but the quick version is to put something like

<commandline xmlns="http://libvirt.org/schemas/domain/qemu/1.0">
  <arg value="-fsdev"/>
  <arg value="local,security_model=mapped,id=fsdev-fs0,path=/path/to/share,fmode=0644,dmode=0755"/>
  <arg value="-device"/>
  <arg value="virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=sharename,bus=pci.6,addr=0x0"/>
</commandline>

into your domain XML as a child of "domain." The blog post goes into more detail about the values but you may need to tweak fsdev-fs0, fs0, and sharename to fit your domain.

Best Answer

Related Solutions

Why is the default umask value for useradd in openSUSE set to 022

Linux – Setting umask of libvirt/virt-manager for proper permissions in a directory shared by host and guest

Related Question