Bug 1174278 - ecryptfs doesn't automount Private at login since upgrade to FC21 beta
Summary: ecryptfs doesn't automount Private at login since upgrade to FC21 beta
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 21
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1165578 (view as bug list)
Depends On: 1165578
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-15 14:42 UTC by Miroslav Grepl
Modified: 2015-02-05 14:18 UTC (History)
17 users (show)

Fixed In Version: selinux-policy-3.13.1-105.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of: 1165578
Environment:
Last Closed: 2015-01-30 23:54:41 UTC
Type: Bug


Attachments (Terms of Use)

Description Miroslav Grepl 2014-12-15 14:42:44 UTC
+++ This bug was initially created as a clone of Bug #1165578 +++

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

--- Additional comment from Michal Hlavinka on 2014-11-19 04:57:26 EST ---

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

--- Additional comment from Swâmi Petaramesh on 2014-11-19 05:14:29 EST ---

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.

--- Additional comment from Miroslav Grepl on 2014-11-21 05:01:40 EST ---

Could you please make sure your system is labeled correctly.

# touch /.autorelabel; reboot

and re-test it in permissive mode.

Thank you.

--- Additional comment from Swâmi Petaramesh on 2014-11-21 05:18:06 EST ---

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).

--- Additional comment from Swâmi Petaramesh on 2014-11-25 04:44:33 EST ---

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

--- Additional comment from Swâmi Petaramesh on 2014-12-04 10:25:53 EST ---

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.

--- Additional comment from Miroslav Grepl on 2014-12-05 09:07:08 EST ---

Ok what does

# ps -efZ kdm

# ps -efZ sshd

if you log in?

--- Additional comment from Swâmi Petaramesh on 2014-12-05 09:17:59 EST ---

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

--- Additional comment from Miroslav Grepl on 2014-12-05 10:22:14 EST ---

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

?

--- Additional comment from Swâmi Petaramesh on 2014-12-05 10:29:56 EST ---

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

--- Additional comment from Miroslav Grepl on 2014-12-05 11:27:28 EST ---

The problem is mount.ecryptfs_private is not executed by kdm running as xdm_t.

Michal,
are you able to reproduce it?

--- Additional comment from Dominik Grafenhofer on 2014-12-06 05:06:21 EST ---

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)

--- Additional comment from Dominik Grafenhofer on 2014-12-06 05:07:32 EST ---



--- Additional comment from Dominik Grafenhofer on 2014-12-06 05:08:46 EST ---



--- Additional comment from Miroslav Grepl on 2014-12-08 10:02:39 EST ---

Michal,
was there a change in PAM ecrypfs handling in F21?

--- Additional comment from Dominik Grafenhofer on 2014-12-08 10:12:21 EST ---

> 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.

--- Additional comment from Swâmi Petaramesh on 2014-12-08 10:19:36 EST ---

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

--- Additional comment from Michal Hlavinka on 2014-12-08 10:39:04 EST ---

(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?

--- Additional comment from Swâmi Petaramesh on 2014-12-08 10:45:16 EST ---

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...

--- Additional comment from Dominik Grafenhofer on 2014-12-08 10:58:02 EST ---

(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.

--- Additional comment from Miroslav Grepl on 2014-12-09 09:04:03 EST ---



--- Additional comment from Miroslav Grepl on 2014-12-09 10:00:23 EST ---

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.

--- Additional comment from Dominik Grafenhofer on 2014-12-09 10:46:36 EST ---

@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.

--- Additional comment from Kevin R. Page on 2014-12-10 14:34:53 EST ---

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.

--- Additional comment from Kevin R. Page on 2014-12-11 03:57:46 EST ---

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?

--- Additional comment from  on 2014-12-11 04:27:38 EST ---

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.

--- Additional comment from Miroslav Grepl on 2014-12-11 06:29:23 EST ---

How I wrote not sure how it could work on F20. My point is we need to fix PAM handling for ecryptfs.

--- Additional comment from Kevin R. Page on 2014-12-11 07:42:30 EST ---

(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.

--- Additional comment from Tore Anderson on 2014-12-11 09:01:54 EST ---

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.)

--- Additional comment from Swâmi Petaramesh on 2014-12-11 09:03:38 EST ---

Hu-hu. Looks like this one is getting a bit hot :-]

--- Additional comment from Michal Hlavinka on 2014-12-11 12:31:44 EST ---

(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?

--- Additional comment from Paul DeStefano on 2014-12-11 13:48:02 EST ---

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.

--- Additional comment from Paul DeStefano on 2014-12-11 13:56:34 EST ---

> 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.

--- Additional comment from Miroslav Grepl on 2014-12-11 15:26:26 EST ---

(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

--- Additional comment from Paul DeStefano on 2014-12-11 17:19:29 EST ---

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?

--- Additional comment from Kevin R. Page on 2014-12-11 18:00:19 EST ---

(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

--- Additional comment from  on 2014-12-12 03:43:04 EST ---

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.

--- Additional comment from Piergiorgio Sartor on 2014-12-13 12:22:14 EST ---

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

--- Additional comment from Miroslav Grepl on 2014-12-15 09:41:30 EST ---

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;

Comment 1 Kevin R. Page 2014-12-18 11:20:23 UTC
(In reply to timok from comment #37)
> 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

Just to note that my install was a fresh F20 install on a new laptop made approx. 2 months ago, in case that's a helpful data point.

Comment 2 Miroslav Grepl 2015-01-06 12:55:50 UTC
commit cf4b4f746f42e7c9ed8e6c3cc1d0c9ddbe6aaf82
Author: Dan Walsh <dwalsh@redhat.com>
Date:   Tue Dec 23 14:45:22 2014 -0500

    Allow userdomains to use mount commands as entrypoints

Comment 3 Paul DeStefano 2015-01-13 21:51:28 UTC
Finally got a chance to remove all my local policies and try selinux-policy-3.13.1-103.  Works fine.  None of the policies I made with audit2allow are required anymore.

Thank you!

Comment 4 Michael Lipp 2015-01-15 23:13:36 UTC
Doesn't work for me with selinux-policy-3.13.1-103.

Comment 5 Paul DeStefano 2015-01-15 23:41:12 UTC
Oops.  Must have dont my test wrong because after rebooting, ecryptfs failed to mount my home.  Had to reinstall policies I removed thinking it was fixed.

Comment 6 Swâmi Petaramesh 2015-01-16 08:00:32 UTC
Still does not work here with 
selinux-policy-3.13.1-103.fc21.noarch
selinux-policy-targeted-3.13.1-103.fc21.noarch

Comment 7 Michael Lipp 2015-01-16 19:49:36 UTC
(In reply to Paul DeStefano from comment #5)
> Oops.  Must have dont my test wrong because after rebooting, ecryptfs failed
> to mount my home.  Had to reinstall policies I removed thinking it was fixed.

Could you please send me your policies for a workaround? Using audit2allow I could make the mount work for ssh, but the unmount doesn't work (doesn't produce anything in the log).

Comment 8 Paul DeStefano 2015-01-18 08:08:55 UTC
I don't run SSHD on this box, so I would know about that vector, only X11 and console.  I'd be intersted in seeing your policy for that.

These are the two policies I have installed now:

module myPol.login 1.0;

require {
        type unconfined_t;
        type mount_ecryptfs_exec_t;
        class file entrypoint;
}

#============= unconfined_t ==============
allow unconfined_t mount_ecryptfs_exec_t:file entrypoint;


module myPol.systemd-logind 1.0;

require {
        type systemd_logind_t;
        type mount_ecryptfs_tmpfs_t;
        class file getattr;
}

#============= systemd_logind_t ==============
allow systemd_logind_t mount_ecryptfs_tmpfs_t:file getattr;

Comment 10 Fedora Update System 2015-01-27 16:49:17 UTC
selinux-policy-3.13.1-105.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-105.fc21

Comment 11 Michael Lipp 2015-01-27 18:15:27 UTC
The good news is that mounting works (tried for both ssh and gnome).

The bad thing is that unmounting does not work. I don't know if this should go to a new bug (since the title mentions only mounting, the umounting bug having been "shadowed" up to now).

Unmounting works when executing /sbin/umount.ecryptfs_private from the command line while logged on. It fails when the same command is executing by pam_ecryptfs.so on logout.

I have modified pam_ecrypts.so to redirect umount.ecryptfs_private's error messages to syslog. I get:

fopen: Permission denied
Cannot chdir into mountpoint.

As everything works when I disable selinux, I suppose that pam_ecryptfs.so runs with a different security context than the user's login shell, so still some rules missing here...

Comment 12 Michael Lipp 2015-01-27 18:39:08 UTC
(In reply to Michael Lipp from comment #11)
> The bad thing is that unmounting does not work. I don't know if this should
> go to a new bug (since the title mentions only mounting, the umounting bug
> having been "shadowed" up to now).

I withdraw that. Now it works (both mounting and unmounting), not sure what happened before...

Comment 13 Fedora Update System 2015-01-30 04:32:13 UTC
Package selinux-policy-3.13.1-105.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-105.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-1337/selinux-policy-3.13.1-105.fc21
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2015-01-30 23:54:41 UTC
selinux-policy-3.13.1-105.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Kevin R. Page 2015-02-05 11:30:00 UTC
The update, in combination with the fix for bug #1165578 has fixed the issue for me. Thanks.

Comment 16 Michal Hlavinka 2015-02-05 14:18:37 UTC
*** Bug 1165578 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.