Description of problem: Since upgrading from FC20 to FC21 beta, ecryptfs doesn't auto-mount my "Private" directory at login anymore. However, mounting it manually using "ecryptfs-mount-private" afterwards still works. Version-Release number of selected component (if applicable): ecryptfs-utils-103-6.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. get a FC20 system with ecryptfs and working automount at login 2. Upgrade to FC21 beta 3. It doesn't work anymore
Could you please test it with selinux disabled or in permissive mode? During boot, edit boot options in group and on the line "vmlinuz ...." add "enforcing=0" Alternatively, before logging in after fresh boot, switch to console (ctrl-alt-f2), log in as root and do setenforce 0 both methods will change your selinux to permissive mode temporarily, it will be back enforcing (if you have it set up that way) after reboot. Once you have that set up, verify it with "sestatus" command, which should print "Current mode: permissive". Then try to log in as normal user and check if Private gets automounted. If still does not, paste here output of: journal -b | grep -i ecrypt and grep -i ecrypt /var/log/secure | tail -n 50 Thanks
Hi Michal, Looks like this is (yet another) SELINUX issue. Starting up with "enforcing=0", the ecryptfs directory does get automounted at login, as expected. My audit.log spits a number of "denials", some explicitly about ecryptfs and others about kdm : type=USER_AUTH msg=audit(1416391633.432:393): pid=1724 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantor=pam_unix,pam_kwallet,pam _ecryptfs acct="michel" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1416391633.434:394): pid=1724 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantor=pam_unix,pam_localuser acct= "michel" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1416391633.438:395): pid=1724 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantor=pam_unix,pam_kwallet,pam_ecryptf s acct="michel" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1416391633.438:396): pid=1724 uid=0 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295 auid=1000 old-ses=4294967295 ses=2 res=1 type=USER_ROLE_CHANGE msg=audit(1416391633.488:397): pid=1724 uid=0 auid=1000 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 -s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1416391633.518:398): pid=1859 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting grantor=pam_unix,pam_localuser acct="michel" ex e="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1416391633.520:399): pid=1859 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:session_open grantor=pam_keyinit,pam_limits,pam_systemd,p am_unix acct="michel" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=SERVICE_START msg=audit(1416391633.530:400): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="user@1000" exe="/usr/lib/systemd/systemd" hostname=? addr =? terminal=? res=success' type=AVC msg=audit(1416391633.868:401): avc: denied { entrypoint } for pid=1865 comm="kdm" path="/usr/sbin/mount.ecryptfs_private" dev="dm-1" ino=1165501 scontext=unconfined_u:unconfined_r:unc onfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1416391633.868:401): arch=c000003e syscall=59 success=yes exit=0 a0=7f49b3b65a89 a1=7fff8a331380 a2=0 a3=7f49b78f7310 items=0 ppid=1724 pid=1865 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="mount.ecryptfs_" exe="/usr/sbin/mount.ecryptfs_private" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key =(null) type=PROCTITLE msg=audit(1416391633.868:401): proctitle="mount.ecryptfs_private" type=USER_START msg=audit(1416391633.878:402): pid=1724 uid=0 auid=1000 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantor=pam_selinux,pam_loginuid,pam_selinux,pam _keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_kwallet,pam_ecryptfs,pam_lastlog acct="michel" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success' type=AVC msg=audit(1416391633.880:403): avc: denied { write } for pid=1866 comm="kdm" name="michel" dev="dm-1" ino=256 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_ r:unlabeled_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1416391633.880:403): avc: denied { remove_name } for pid=1866 comm="kdm" name=".xsession-errors" dev="dm-1" ino=609790 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tconte xt=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1 type=SYSCALL msg=audit(1416391633.880:403): arch=c000003e syscall=87 success=yes exit=0 a0=7f49bb340140 a1=0 a2=7f49bb340140 a3=20 items=0 ppid=1724 pid=1866 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=PROCTITLE msg=audit(1416391633.880:403): proctitle="-:0'" type=AVC msg=audit(1416391633.880:404): avc: denied { add_name } for pid=1866 comm="kdm" name=".xsession-errors" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unla beled_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1416391633.880:404): avc: denied { create } for pid=1866 comm="kdm" name=".xsession-errors" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabe led_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416391633.880:404): avc: denied { append open } for pid=1866 comm="kdm" path="/home/michel/.xsession-errors" dev="dm-1" ino=611554 scontext=system_u:system_r:xdm_t:s0-s0:c0 .c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1416391633.880:404): arch=c000003e syscall=2 success=yes exit=3 a0=7f49bb340140 a1=4c1 a2=180 a3=20 items=0 ppid=1724 pid=1866 auid=1000 uid=1000 gid=1000 euid=1000 suid=10 00 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Kind regards.
Could you please make sure your system is labeled correctly. # touch /.autorelabel; reboot and re-test it in permissive mode. Thank you.
Hi, I had already relabeled the system as you suggest, before reporting this, and the above extract of my audit.log has been made in "permissive" mode (where it works).
Hi, still getting in audit.log things such as : type=AVC msg=audit(1416903473.629:373): avc: denied { entrypoint } for pid=1700 comm="kdm" path="/usr/sbin/mount.ecryptfs_private" dev="dm-1" ino=1165501 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416851447.042:744): avc: denied { entrypoint } for pid=4872 comm="sshd" path="/usr/sbin/mount.ecryptfs_private" dev="dm-1" ino=1165501 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=0
For the record, I've seen that today there was an update of packages : - selinux-policy-3.13.1-99.fc21.noarch - selinux-policy-targeted-3.13.1-99.fc21.noarch ...and this update did NOT fix this issue. Best regards.
Ok what does # ps -efZ kdm # ps -efZ sshd if you log in?
Err... # ps -efZ kdm error: unknown sort specifier # ps -efZ sshd error: unsupported option (BSD syntax) Maybe you want : # ps Z -C kdm LABEL PID TTY STAT TIME COMMAND system_u:system_r:xdm_t:s0-s0:c0.c1023 1638 ? Ss 0:00 /usr/bin/kdm vt1 system_u:system_r:xdm_t:s0-s0:c0.c1023 1701 ? SL 0:00 -:0 # ps Z -C sshd LABEL PID TTY STAT TIME COMMAND system_u:system_r:sshd_t:s0-s0:c0.c1023 1633 ? Ss 0:00 /usr/sbin/sshd -D
Ah yes, I mean "grep" in commands. Ok it looks correct. And you are still able to reproduce https://bugzilla.redhat.com/show_bug.cgi?id=1165578#c5 ?
Now Im getting exactly this AVC type=AVC msg=audit(1417791043.555:378): avc: denied { entrypoint } for pid=1714 comm="kdm" path="/usr/sbin/mount.ecryptfs_private" dev="dm-1" ino=1165501 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=1
The problem is mount.ecryptfs_private is not executed by kdm running as xdm_t. Michal, are you able to reproduce it?
I guess I have a similar (but maybe exactly the same) problem (ecryptfs home, upgrade from F-20): There is a selinux problem, which could be identical to the one discribed above. In trying to track down the problem I temporaritly turned off selinux: Doing this I am able to properly log in on the console (home directory get decrypted and mounted). Still login via GDM (I am using Gnome) fails. Instead of logging in, I get back to the GDM login screen. Maybe the KDM problem is related. It seems that GDM does not decrypt my home directory. Logfiles: console_login_success.log gdm_login_failure.log (there might be unrelated log content at the end of the log)
Created attachment 965400 [details] Log file of successful login on console after selinux has been turned off
Created attachment 965401 [details] Log file of failed login via gdm after selinux has been turned off
Michal, was there a change in PAM ecrypfs handling in F21?
> was there a change in PAM ecrypfs handling in F21? I should have mentioned that the problem occured also in F20 when "upgrading" to Gnome 3.12 via the COPR by rhughes.
I don't see no change in the way that PAM handles ecryptfs in FC21 compared to FC20. AFAIK it is only mentioned in /etc/pam.d/postlogin-ac (managed by authconfig), and on my system, this file, after upgrade to FC21 is exactly the same as before (as I have filesystem snaphots, I can easily compare the current state of the file to what it was before upgrading to FC21... Here, /etc/pam.d/postlogin-ac contains : # cat postlogin-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth optional pam_ecryptfs.so unwrap password optional pam_ecryptfs.so unwrap session optional pam_ecryptfs.so unwrap session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed
(In reply to Miroslav Grepl from comment #15) > Michal, > was there a change in PAM ecrypfs handling in F21? no, we did not change anything for a loooong time (In reply to Miroslav Grepl from comment #11) > Michal, > are you able to reproduce it? No, it worked for me. BUT I tried it as user-switching, not as my first and only session, as I can't logout and terminate all my applications, now. PS: Why was component switched from selinux to ecryptfs?
Yes, that's a SELINUX issue, not an ecryptfs one. As soon as the system is booted with the "enforcing=0" parameter, pushing SELINUX out of the way, then it works...
(In reply to Swâmi Petaramesh from comment #19) > Yes, that's a SELINUX issue, not an ecryptfs one. As soon as the system is > booted with the "enforcing=0" parameter, pushing SELINUX out of the way, > then it works... The log files I posted are with SELINUX turned off ("enforcing=0"). There has to be a seperate GDM/Gnome issue.
*** Bug 1169103 has been marked as a duplicate of this bug. ***
I don't see a way how it could work on F20. Basically this is about PAM handling where we call it after "pam_selinux.so open" which means we end up wit a SELinux userdomain.
@Miroslav Grepl: You are right, there was a SELINUX error under F20 as well (at least in my case). After fixing the SELINUX problem (or after turning SELINUX off), login did work under F20 and Gnome 3.10. It does not work under F20/Gnome 3.12 and F21 though.
I have just updated from F20 to F21 using fedup. All my user accounts use ecryptfs and none mount either through GDM, on console, or via ssh. Please add this to F21 Common Bugs ASAP to stop others from upgrading without knowing this bug exists. I respectfully suggest it also ought to be a higher severity than "low" now that F21 has shipped with this regression -- it's going to hit anyone using ecryptfs.
For added context: I had a working setup with selinux enforcing in F20. I think I recall selinux/ecryptfs problems early in the release which caused issues (not this severe) but these were resolved. This bug needs assigning to selinux-policy, doesn't it?
I can more or less confirm Kevin's post. In F20 it worked with selinux enforcing. In F21 it does not work anymore. But I can go to the console, mount my home folder and then access my account via GDM. Please set the priority higher! This way ecryptfs is not really usable with GDM.
How I wrote not sure how it could work on F20. My point is we need to fix PAM handling for ecryptfs.
(In reply to Miroslav Grepl from comment #27) > How I wrote not sure how it could work on F20. My point is we need to fix > PAM handling for ecryptfs. I am writing this now on a laptop running F20, with my home directory on ecryptfs, automounted on login with gdm, and selinux enforcing. Please let me know if you'd like me to attach any config to the bug. There may well be a deeper issue, but initially could we please just get back to the situation on F20, which for several of us at least was "working". Please, also, could someone with privs on this bug add the keyword CommonBugs or you'll be getting many more users as they upgrade to F21.
Note it's not only GDM, I had the same problem with LXDM too. Worked fine in F20 and it broke after an upgrade. (See bug #1169103 for details.)
Hu-hu. Looks like this one is getting a bit hot :-]
(In reply to Miroslav Grepl from comment #27) > How I wrote not sure how it could work on F20. My point is we need to fix > PAM handling for ecryptfs. What exactly do you mean?
Me too. I'm using xfce. I get this too on when loging in on virtual console: SELinux is preventing /usr/bin/login from entrypoint acces on the file /usr/sbin/mount/.ecryptfs_private. I see the same SELinux msg for /usr/lib/systemd/systemd-logind. I'm assuming that comes from logging in via lightdm, (the new dm for all non-Gnome/non-KDE envs?). Guess I will try my own SELinux rule, but it may be a rabbit hole. FWIW, I'v been using ecryptfs home directory (w/ pam auto-mount) since at least August 2012, according to time stamps. That must have been F19 or even earlier.
> SELinux is preventing /usr/bin/login from entrypoint acces on the file > /usr/sbin/mount/.ecryptfs_private. > > I see the same SELinux msg for /usr/lib/systemd/systemd-logind. Oops, sorry, both messages are from logging in on the console, and they are actually different targets. systemd-logind is prevented from getattr access on /dev/shm/ecryptfs-<my-username>-Private.
(In reply to Kevin R. Page from comment #28) > (In reply to Miroslav Grepl from comment #27) > > How I wrote not sure how it could work on F20. My point is we need to fix > > PAM handling for ecryptfs. > > I am writing this now on a laptop running F20, with my home directory on > ecryptfs, automounted on login with gdm, and selinux enforcing. > > Please let me know if you'd like me to attach any config to the bug. > > There may well be a deeper issue, but initially could we please just get > back to the situation on F20, which for several of us at least was "working". > > Please, also, could someone with privs on this bug add the keyword > CommonBugs or you'll be getting many more users as they upgrade to F21. Kevin, how is labeled /usr/sbin/mount.ecryptfs_private on your system? ls -Z /usr/sbin/mount.ecryptfs_private
Well, I'm up and running again after creating two new SELinux policy modules. The policy for systemd-logind looks okay. But, the one audit2allow created from the errors related to 'login' seems unacceptably broad, but I really don't know what I'm reading. Let me know if I can be of more help. Can this get into the test harness for Fedora, somehow? Seems to hit on every upgrade. I take it this is not a supported use case?
(In reply to Miroslav Grepl from comment #34) > how is labeled /usr/sbin/mount.ecryptfs_private on your system? F20: -rwsr-x---. root ecryptfs system_u:object_r:mount_exec_t:s0 /usr/sbin/mount.ecryptfs_private F21: -rwsr-x---. root ecryptfs system_u:object_r:mount_ecryptfs_exec_t:s0 /usr/sbin/mount.ecryptfs_private
I just ran 'ls -Z /usr/sbin/mount.ecryptfs_private' on my system (F21 after fedup from F20, ecryptfs_private worked on F20, does not on F21) and the output is different from Kevin: -rwsr-xr-x. root root system_u:object_r:mount_ecryptfs_exec_t:s0 /usr/sbin/mount.ecryptfs_private Nevertheless, I have a group named ecryptfs and my user is member of this group. I do not see a real difference in output, but maybe it does matter.
Hi all, I've the same problem, after upgrading from F20 to F21 the ~/Private folder is not "activated" anymore on GDM login. There are some differences with the cases here reported. On my PC, SELinux is completely disabled. Second, if I login from console, it works without problems, it is only GDM that does not allow/execute the decryption. Hope this helps, bye, pg
Ok I finally see what changes cause this issue with enabled SELinux. Basically we removed a general rule which was wrong and now we get this real issue which was covered by this rule. A quick workaround is a rule like allow unconfined_t mount_ecryptfs_exec_t:file entrypoint;
Miroslav: Shouldn't this bug be reassigned back to selinux? Piergiorgio: If it does not work with selinux disabled, then it's different issue. Open new bug. thanks
I created a poliy clone. I believe we should talk above PAM handling.
I also experience this bug. But in my case it does not seem SELinux related to me. I do have it enabled, but when I disabled it to test this theory it did not help. So I looked round and noticed that mounting the ecryptfs is done a bit different in Fedora than it is under a Debian/Ubuntu platform. On Debian/Ubuntu the "pam_ecryptfs.so unwrap" bits are placed in /etc/pam.d/system-auth. On Fedora we put those bits in /etc/pam.d/postlogin. Perfectly alright. But when looking around i found a commit to GDM titled "[gdm] pam: drop postlogin from fedora pam config". It can be found here: https://mail.gnome.org/archives/commits-list/2014-April/msg03907.html Short version of what it does to the GDM login procedure: -auth include postlogin Gives me the idea that /etc/pam.d/postlogin is not read anymore. So our "pam_ecryptfs.so unwrap" bits end up getting skipped completely. :( For starters: I'm going to try placing the "pam_ecryptfs.so unwrap" bits in /etc/pam.d/system-auth. So where that gets me. Could I be onto something here, or do I need to dig a bit deeper?
Stefan, if it's not SELinux related, but GDM related, please continue in bug #1174366 Anyway, thanks for your investigation.
after fixing bug #1174366 by readding postlogin pam-configuration back to gdm, I added the following to selinux, to get ecryptfs-mount-private to be run on gdm login: # grep gdm-session-wor /var/log/audit/audit.log | grep denied type=AVC msg=audit(1421100470.645:405): avc: denied { entrypoint } for pid=1675 comm="gdm-session-wor" path="/usr/sbin/mount.ecryptfs_private" dev="dm-1" ino=803964 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=0 # grep gdm-session-wor /var/log/audit/audit.log | grep denied | audit2allow -M ecryptfs # semodule -i ecryptfs.pp
bug 1174278 was updated with a note about a new policy for this issue. I removed all the policies I had installed using audit2allow and I think everything is working okay with out them. So, I think this is fixed.
(In reply to Paul DeStefano from comment #45) > bug 1174278 was updated with a note about a new policy for this issue. I > removed all the policies I had installed using audit2allow and I think > everything is working okay with out them. So, I think this is fixed. I take it back. I rebooted and ecryptfs wasn't able to mount my home directory. I had to re install the two policy files I created with audit2allow. So, I must not have run the test properly. Still not fixed AFAICT.
For me, this bug was solved by upgrading to selinux-policy-3.13.1-105.fc21.noarch Thanks !
For me, it also works fine now with the stable selinux-policy-3.13.1-105.fc21.noarch. So this bug can be closed-fixed.
The update, in combination with the fixes for bug #1174278 (selinux) and bug #1174366 (gdm) has fixed the issue for me. Thanks.
*** This bug has been marked as a duplicate of bug 1174278 ***
I do not know whether this is the right place but the problem appeared again. It was fixed with the mentioned version but now, I observe the same behavior. I also disabled selinux for testing, but that did not help. Here are some system details: F21 gdm: 3.14.1-2 selinux-policy: 3.13.1-105.3 ecryptfs-utils: 103-7 If I can provide any information or someone can confirm the reappearance of the problem please let me know.
@timo: I cannot reproduce the problem on F21 (gdm: 3.14.1-2, selinux-policy: 3.13.1-105.3, ecryptfs-utils: 103-7). Login still works for me (even with selinux turned on)!
@Dominik: This is really strange. I did not change a thing but updating from the official and fusion repos. Had the notebook not running for approx. two weeks and now it does not work anymore. Seems strange to me but if it works for you it must be somewhere on my system.