pam_umask USERGROUPS_ENAB option broken

[crash]

Using Mint 13 / Cinnamon 64bit

Per documentation, the new behavior for PAM umask should be to change default umask from 022 to 002 if USERGROUPS_ENAB is enabled in /etc/login.defs and username = group or UID=GID. This is not happening.

[mapatma (mpat)]

Using Mint14/Cinnamon 64. I have a very similar issue which I think is the same bug. I think PAM is not setting the umask at all when logging in via mdm.

/etc/login.defs contains the following:
UMASK 027
USERGROUPS_ENAB yes

and users are in their own private groups.

Logging in via mdm and in a terminal emulator the umask is set to some unconfigured value (it is not set in either /etc/profile or ~/.profile). If I log in via the command line (either via su or using CTRL-ALT-F1 etc) then pam_umask works as expected:

matt@matt-X201 ~ $ umask
0022
matt@matt-X201 ~ $ su matt
Password:
matt@matt-X201 ~ $ umask
0007

As a test I have also tried explicitly setting the umask in /etc/pam.d/common-session by modifying the pam_umask.so line:
session optional pam_umask.so umask=001

This gives the same behaviour:
matt@matt-X201 ~ $ umask
0022
matt@matt-X201 ~ $ su matt
Password:
matt@matt-X201 ~ $ umask
0001

I have checked the mdm pam configuration and it sources common-session:
matt@matt-X201 ~ $ grep common-session /etc/pam.d/mdm
@include common-session

This suggests to me that the problem is with mdm.

[crash (crash369)]

Concur with above: mdm may be the culprit

Doing some trial and error, logging in with the graphical interface will ignore umask settings in the following files:

/etc/pam.d/login
/etc/pam.d/mdm
/etc/pam.d/common-session
/etc/login.defs

When logging in through the terminal, umask and usergroups_enab settings work as expected

[pulpo88 (zymurgent)]

Mint 15/Cinnamon, same behavior

[Carl (isopropyl)]

See also https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1093396.

[Kerrigan Joseph (karjaneth)]

I'm running Linux Mint 16 Mate, fully updated, and I'm having an issue I believe to be related to this bug, but I want to make sure so that if it's different, I can submit a new bug. I'll try to keep it brief.

I have an SMB share on a (Debian) file server mounted on my machine, and the share in the smb.conf file on the server has the following settings (among others):

create mask = 0770
directory mask = 0770
force create mode = 0770

additionally, on the server, the sticky bit is on for the folder being shared. As a result, folders created in the mounted share from the terminal on the client (my Mint computer) have permissions of rwxrws--- by default (as expected), but creating a new folder in caja leads to permissions of rwxr-s--- for some reason. This does not occur for files; they have permissions of rwxrwx--- regardless of where they're created from. Files and folders created from Windows clients also have the expected behavior.

The following (rather ancient) thread from Gentoo seems to describe an identical problem, but the OP's problems were resolved by a gnome update (also ancient).

Is this the same bug or different?

[altair4 (altair4mint)]

I had hoped that this would have been fixed by now at least fixed in Mint17 but that appears not to be the case. I had hoped that it was because of an Ubuntu upstart bug but that was fixed in Ubuntu 14.04 and yet this problem persists in Mint17.

An earlier entry by Matt Patey more that a year ago suggested the problem may be with mdm and not some other internal source. So on a whim I used a howto on the mint forums ( http://forums.linuxmint.com/viewtopic.php?f=42&t=145261 ) to switch from mdm to lightdm in Mint17 Cinnamon.

Guess what? My default umask is 0002. Just as it should be. Just as it is in Ubuntu 14.04.

Short of switching dm's, using something like bindfs, or going with Ubuntu is there an better work around for this issue?

[pete s (petescomp)]

i had the same problem on mint 17 and i don't know whether this is one of the old ways but there is a solution/workaround that works for me from http://www.linuxfromscratch.org/blfs/view/cvs/postlfs/profile.html via https://plus.google.com/+StevenRose-Main/posts/8r1PKGqEXcd hope it is of some use