New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pam_fscrypt messes up user groups during login #77
Comments
|
Add |
|
@fancytenseletters Hmm, I just tried that but it doesn't make any difference unfortunately :( Same thing is still happening. I removed it from |
|
@Minecrell can you try uncommenting |
|
@fancytenseletters Yeah, I disabled I copied your config as-is to |
|
Perhaps there is some bug in fscrypt. Also, can you try to create and encrypt some folder and try to relogin? How do you login? Console/sddm/lightdm/gdm? |
|
@fancytenseletters Sure, I appreciate your help! :) Normally I use lightdm, but for testing I have disabled it and just login from the default console login prompt. For some reason, login in lightdm is entirely broken with I've posted the files and logs (for console login and lightdm login) at https://gist.github.com/Minecrell/33fea177022b36313d357a3c5994b9d9 The folder I created is unlocked correctly, but with console login the group is wrong and with lightdm it doesn't even log in properly. |
|
Do you have https://www.archlinux.org/packages/extra/x86_64/accountsservice/ package installed? |
|
I did not, but I just installed it and it doesn't make any difference either :( |
|
I just realized I am also experiencing this bug. In my case, my user is not in the |
|
Should we keep the EDIT: I can confirm doing this change appears to fix the groups issue for me as well. |
|
@Minecrell can you confirm that adding |
|
Doesn't seem to make any difference for me :( I still get: ... with these configs & logs: https://gist.github.com/Minecrell/53e478dc8495c93357a6bf38449fff39 |
|
@Minecrell I just compared your config files with mine and they look identical except for the |
|
As I was looking into reproducing #93 I managed to reproduce this bug. Here's a QEMU VM that triggers the bug running HEAD: https://drive.google.com/open?id=1soLFKOoFHK47d31RCn6qmJB7AORe2ysg Uncompress (using xz, no tarball) and launch using virt-manager. Fedora 26 settings. Two users: root and qemu, both have the same password: qemu. User qemu's home is encrypted, PAM unlocking is setup. |
|
@sebadoom, this is great, will investigate tonight. |
|
For me, the simple change that makes this happen was when I added pam_fscrypt to "/etc/pam.d/systemd-user" on my Ubuntu 18.04 (Bionic) system. Currently, the Ubuntu package does not run pam_fscrypt for /etc/pam.d/common-session-noninteractive which is what systemd-user uses. I was guessing this also means most of the background daemons on login don't have access to the filesystem. In my attempt to resolve this I added pam.d to /etc/pam.d/systemd-user - whether I put it before or after systemd the login groups are messed up, and the session/user keys don't end up linked. My understanding of PAM is really lacking at this point to understand that more.. it sounds like this is going to get replaced by systemd integration never the less thought I'd add the comment. |
|
I've realised part of the issue for me.. gnome-terminal is not actually running as a new process but is instead powered by 'gnome-terminal-server' which runs under the systemd-user session .. so gnome-terminal itself and all commands you run inside of it are "broken" much like other services started by systemd-user in many configurations. |
|
I can reproduce this on a fresh Ubuntu 18.04 installation. It happens for any PAM context where pam_fscrypt is loaded (even if no filesystems are in use) (1) Install 18.04 using http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso Have not debugged how/why it causes the behaviour. Also happens when installing from git |
|
I've debugged this in detail and it boils down to the call to fscrypt/security/privileges.go Lines 100 to 102 in 3e32282
With this commented out, the user groups are correct after login. Otherwise the user is only in the root group. Looking at the source code of Unlike UID and GID, the supplementary group list of the target user is applied before the PAM modules are called. fscrypt breaks this by applying the supplementary groups of the root user when restoring the privileges. There are a few ways to fix this but I'm not sure which one is the best solution:
|
|
Additional note: I haven't checked this in detail, but it seems like Ubuntu might be using Considering we can't rely on having the groups already correct, solution 2 is probably the more reliable one. |
|
@Minecrell thank you so much for reporting this, and it's my bad for missing the security implications of this bug. The fix in #103 is similar to your proposed solution 2. Thanks for the great work in finding this issue. |
I've added
pam_fscryptto/etc/pam.d/system-auth(on Arch Linux) as described in the README:With
pam_fscryptenabled, I'm no longer in thewheelgroup after login for some reason, which means I can no longer usesudo. Instead, it adds me to the root group:With
session optional pam_fscrypt.socommented out:Log:
Any ideas? :)
The text was updated successfully, but these errors were encountered: