66

I am working in a lab where we are running Linux (Debian and Ubuntu). Usernames and group names are handled by NIS and yp. We have some common users that everybody has access to that run the experiments and then we each have our own users in addition there is a common group that we are all a member of.

How can I make such that all files and directories on the shared /home/ drive (NFS) is read/write(/executable) by user/group? Basically what I want is

chmod -R 664 /home
chgrp -R commongroup /home

or equivalently umask 0002.

But running the above commands only fixes the current files in the folders and umask only works for single users and has to be run every time a user logs in ie. in the .bashrc file (and will this work for changes mode via gnome?). Is there a system wide command or setting that I could use to make sure that our commongroup has write access to the common files?

Chris Williams
  • 9,399
  • 14
  • 53
  • 88
HansHarhoff
  • 1,787
  • 2
  • 19
  • 32
  • 2
    i believe you can use `setfacl` to recursively set (and maintain) access settings to a dir. http://linuxcommand.org/man_pages/setfacl1.html – tMC Apr 19 '12 at 02:08
  • 2
    You do *not* want to `chmod -R 644 /home`: this removes the eXecute bit from directories, which makes them unsearchable. – ephemient Apr 19 '12 at 04:02
  • Following up on tMC's comment: If you want this on specific dirs (and optionally subdirs) and not bind it to all(!) files and dirs belonging to a specific user, then use ACLs. Here's [a good answer](http://stackoverflow.com/a/6550059/923794) to a similar question – cfi Mar 15 '14 at 12:31

3 Answers3

97

Both Debian and Ubuntu ship with pam_umask. This allows you to configure umask in /etc/login.defs and have them apply system-wide, regardless of how a user logs in.

To enable it, you may need to add a line to /etc/pam.d/common-session reading

session optional pam_umask.so

or it may already be enabled. Then edit /etc/login.defs and change the UMASK line to

UMASK           002

(the default is 022).

Note that users may still override umask in their own ~/.profile or ~/.bashrc or similar, but (at least on new Debian and Ubuntu installations) there shouldn't be any overriding of umask in /etc/profile or /etc/bash.bashrc. (If there are, just remove them.)

ephemient
  • 180,829
  • 34
  • 259
  • 378
  • 3
    In 12.04 it's enabled by default. – Ken J Mar 06 '13 at 14:30
  • 6
    debian 7 does **not** have this enabled by default. – earthmeLon Apr 09 '14 at 15:41
  • 1
    how to set a custom umask to one specific user? – brauliobo Aug 01 '14 at 00:25
  • I gave more complete information in a separate answer. This answer will work, but I don't think it is the best way. – Yitz Mar 18 '15 at 14:13
  • Does this mean you cannot set the umask for access to the NFS share alone? Not even on the server? So if you want a different umask for regular access on the local filesystems, and for the NFS mount, you need to create an additional user? – Xennex81 Jul 07 '16 at 11:04
26

First, make sure that the pam-modules package is installed. That makes the pam_umask module available. Then make sure that /etc/pam.d/common-session has a line of the form

session optional pam_umask.so

so that pam_umask is enabled.

Now, according to the pam_umask man page, the default umask is determined at login by checking each of the following places, in order:

  1. A hard system-wide default set in /etc/pam.d/common-session. To set it this way, replace the line from that file mentioned above with this:

    session optional pam_umask.so umask=002
    
  2. An entry in an individual user's GECOS field in /etc/passwd overrides a soft system-wide default for that specific user. Create that entry using a command of the form:

    chfn --other='umask=002' username
    
  3. An line of the form UMASK=002 in /etc/default/login (you may need to create that file) sets a soft system-wide default.

  4. The UMASK value from /etc/login.defs. That value is also used for something else (computing the permissions on the home directory of a new user that is being created; see the comments in /etc/login.defs for more details). So it is best to avoid relying on this for setting the default umask for regular logins, to keep things separate.

So in your case, you should configure this either in /etc/default/login if you want it to be possible to override the setting for individual users, or set it in /etc/pam.d/common-session as described above if you want it to be the same for all users.

Note that even with the hard default setting, users can still override the default umask manually by using the umask command at the shell prompt or in their .profile script.

Also note that the traditional Unix way to set this default is by adding a umask command to /etc/profile, and that would also still work. But it's not the recommended way to configure things like this on Ubuntu, because that is hard to manage reliably using scripts and GUIs.

Note, unfortunately this stopped working for any application which has been converted to launch via systemd --user.

sourcejedi
  • 2,496
  • 19
  • 35
Yitz
  • 4,887
  • 21
  • 19
  • 2
    There is `USERGROUPS_ENAB` options that can change `022` to `002` in some cases. – Ivan Black Jul 13 '16 at 09:02
  • In Ubuntu Server 16.04.1, package `libpam-modules` contains module `pam_umask`. (Command `dpkg-query --search /lib/x86_64-linux-gnu/security/pam_umask.so` prints `libpam-modules:amd64: /lib/x86_64-linux-gnu/security/pam_umask.so`.) – Derek Mahar Oct 31 '16 at 17:45
  • 3
    `/etc/defaults` doesn't exist in Ubuntu Server 16.04.1. Could the correct path be `/etc/default/login`? – Derek Mahar Oct 31 '16 at 19:02
  • Great and complete answer ! – kheraud Jan 22 '18 at 10:36
  • Does it work for Ubuntu 18.04 as well? Mine doesn't work in 18.04. – Smile Feb 24 '19 at 07:32
  • I don' see the advantage of using pam_umask at all? I find it more simple to just set umask in `/etc/profile` and optional `~/.profile`. What's the advantage of using pam-umask? – MrCalvin Apr 03 '21 at 11:17
  • It seems `/etc/profile` is only called when user logon with a shell whereas pam_umask will always set the umask, correct? – MrCalvin Apr 03 '21 at 11:22
0

In order to match up the group rights, on the server, the set gid bit (one of the "sticky bits") can be considered as an additional option.

If the shared directory is linked to the group, launching (using root) : chmod -R 2775 folder_for_the_group may be interesting.

For any new file created in the folder, the creator will be the owner, but the group will be automatically specified (as long as the creator is part of the group).

Rights' grid now appears as -rwxrwsr-x+