Bug 712048
Summary: | SELinux blocks ecryptfs encryption of home dir | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Hlavinka <mhlavink> | ||||||||||||||||||
Component: | ecryptfs-utils | Assignee: | Michal Hlavinka <mhlavink> | ||||||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||||||
Priority: | high | ||||||||||||||||||||
Version: | 20 | CC: | buribullet, catacombae, d.fedora, dominick.grift, dwalsh, esandeen, jaysonsantos2003, jiker, lvrabec, martin.wilck, mgrepl, mhlavink, redhat-bugzilla, redhat, robatino, satellitgo, timok | ||||||||||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||
Clone Of: | |||||||||||||||||||||
: | 1017402 (view as bug list) | Environment: | |||||||||||||||||||
Last Closed: | 2015-03-09 10:35:08 UTC | Type: | --- | ||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||
Embargoed: | |||||||||||||||||||||
Bug Depends On: | |||||||||||||||||||||
Bug Blocks: | 703145, 709158 | ||||||||||||||||||||
Attachments: |
|
Description
Michal Hlavinka
2011-06-09 11:11:32 UTC
Can you also enclose the AVC denials please? #701451 bug Created attachment 503872 [details]
ausearch -m avc -ts 12:50 output
I guess all login_pgm_domains will need to be able set this up, and seems like a good idea to confine umount.ecryptfs command on first sight. (In reply to comment #4) > I guess all login_pgm_domains will need to be able set this up, it looks so, thinking about a boolean. Michal could you explain what is going on when you do this? Does the file system end up being an ext* file system when it is done? Or does the homedir end up labeled ecryptfs_t? ok, so how it works: First, it takes /home/<user> and renames it to /home/<user>.<XXXXX> This directory should be deleted after process completes. Then it sets up encrypted directory /home/<user>. Because ecryptfs needs some encryption configuration data, that are usually in ~/.ecryptfs, it creates new directoriy: /home/.ecryptfs/<user>/.ecryptfs , encrypted data are stored in /home/.ecryptfs/<user>/.Private So it's similar to ~/.ecryptfs and ~/.Private encryption of just ~/Private directory, it's just moved to /home/.ecryptfs/<user> and target directory is /home/<user> instead of /home/<user>/Private Convert script is (must be) executed as root user, so there are no selinux denials at this point. Now, there is: root.root unconfined_u:object_r:home_root_t:s0 /home/.ecryptfs(/.*)? <user>.<user> unconfined_u:object_r:home_root_t:s0 /home/.ecryptfs/<user>(/.*)? <user>.<user> unconfined_u:object_r:home_root_t:s0 /home/<user> <user>.<user> unconfined_u:object_r:user_home_dir_t:s0 /home/<user>.s510Cboq running restorecon -Rv will change home_root_t to user_home_dir_t Should I add restorecon in ecrypts-migrate-home or it's not required? When user tries to log in, selinux produces a lot of messages. Created attachment 504024 [details]
ausearch output (without restorecon)
Created attachment 504025 [details]
ausearch output (with restorecon)
Can you ping me on #selinux so we can talk this out? *** Bug 713799 has been marked as a duplicate of this bug. *** user almost lost his data because of this bug. Just did not complete home migration process because lack of time. As it is now, migration completes, but encryption key is not stored. It means that after reboot, data are still encrypted without any chance to decrypt them. Setting severity to high. My, fault. I dropped this one. Created attachment 526446 [details]
ecrypt local policy
Ok, since extended attr are not supported in this case, it is more complicated to make this working.
I did it with attached local policy. This local policy contains notes which need to be done in the ecrypts-migrate-home script and in the policy.
Dan,
what do you think?
Created attachment 526448 [details]
ecrypt local policy - labels
*** Bug 744618 has been marked as a duplicate of this bug. *** Created attachment 534831 [details]
the test policy for ecryptfs
Just the note: You should be running in permissive mode because of the test policy.
How to install the ecrypt policy
1. Download this attachment
2. tar zxfv ecrypt.tgz
3. cd ecrypt/
4. sh ecrypt.sh <username>
5. setsebool -P use_ecryptfs_home_dirs 1
and try to re-test it.
*** Bug 701451 has been marked as a duplicate of this bug. *** Is this fixed in Fedora 17? I'd like to try migrating home directories to ecryptfs but comment #12 leaves me wary. I've just tested the instructions in comment #17 -- it doesn't work (Fedora 17). With setenforce 0 the can log in but with the audit.log below (obviously fails with setenforce 1). What else should I try? type=AVC msg=audit(1338681693.523:204): avc: denied { getattr } for pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/auto-mount" dev="dm-1" ino=394973 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file type=SYSCALL msg=audit(1338681693.523:204): arch=c000003e syscall=4 success=yes exit=0 a0=768d10 a1=7fffc697b4b0 a2=7fffc697b4b0 a3=1f items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1338681693.524:205): avc: denied { read } for pid=2825 comm="login" name="Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1338681693.524:205): avc: denied { open } for pid=2825 comm="login" name="Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1338681693.524:205): arch=c000003e syscall=2 success=yes exit=5 a0=768d10 a1=0 a2=1b6 a3=238 items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1338681693.524:206): avc: denied { getattr } for pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/Private.mnt" dev="dm-1" ino=1362 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1338681693.524:206): arch=c000003e syscall=5 success=yes exit=0 a0=5 a1=7fffc697b3b0 a2=7fffc697b3b0 a3=0 items=0 ppid=1 pid=2825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=4294967295 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=USER_AUTH msg=audit(1338681693.525:207): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' type=USER_ACCT msg=audit(1338681693.532:208): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' type=CRED_ACQ msg=audit(1338681693.533:209): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' type=LOGIN msg=audit(1338681693.533:210): login pid=2825 uid=0 old auid=4294967295 new auid=1983 old ses=4294967295 new ses=10 type=USER_ROLE_CHANGE msg=audit(1338681693.590:211): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_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/login" hostname=? addr=? terminal=tty3 res=success' type=AVC msg=audit(1338681694.194:212): avc: denied { read } for pid=3050 comm="login" name="wrapped-passphrase" dev="dm-1" ino=394975 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file type=AVC msg=audit(1338681694.194:212): avc: denied { open } for pid=3050 comm="login" name="wrapped-passphrase" dev="dm-1" ino=394975 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file type=SYSCALL msg=audit(1338681694.194:212): arch=c000003e syscall=2 success=yes exit=7 a0=765f60 a1=0 a2=0 a3=7fe8c5cc4f63 items=0 ppid=2825 pid=3050 auid=1983 uid=1983 gid=0 euid=1983 suid=1983 fsuid=1983 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1338681695.114:213): avc: denied { getattr } for pid=2825 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/Private.sig" dev="dm-1" ino=1356 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1338681695.114:213): arch=c000003e syscall=4 success=yes exit=0 a0=765f90 a1=7fffc697b4f0 a2=7fffc697b4f0 a3=20 items=0 ppid=1 pid=2825 auid=1983 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1338681695.116:214): avc: denied { getattr } for pid=3093 comm="login" path="/home/.ecryptfs/lae/.ecryptfs/auto-mount" dev="dm-1" ino=394973 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file type=SYSCALL msg=audit(1338681695.116:214): arch=c000003e syscall=4 success=yes exit=0 a0=765f60 a1=7fffc697b4f0 a2=7fffc697b4f0 a3=7361702d64657070 items=0 ppid=2825 pid=3093 auid=1983 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=10 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null) type=USER_START msg=audit(1338681695.145:215): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' type=CRED_REFR msg=audit(1338681695.145:216): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="lae" exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' type=USER_LOGIN msg=audit(1338681695.146:217): pid=0 uid=0 auid=1983 ses=10 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=1983 exe="/usr/bin/login" hostname=? addr=? terminal=tty3 res=success' Confirmed, SELinux is blocking access to .ecryptfs/wrapped-passphrase during login. Syslog has: ------- login: pam_unix(login:session): session opened for user alice by LOGIN(uid=0) login: ecryptfs: fill_keyring: Passphrase file wrapped login: Error attempting to open [/home/alice/.ecryptfs/wrapped-passphrase] for reading login: Error attempting to unwrap passphrase from file [/home/alice/.ecryptfs/wrapped-passphrase]; rc = [-5] login: ecryptfs: fill_keyring: Error adding passphrase key token to user session keyring; rc = [-5] login: LOGIN ON tty3 BY alice ------- With "setenforce 0", the same login attempt mounts alice's $HOME and syslog has: ------- login: pam_unix(login:session): session opened for user alice by LOGIN(uid=0) login: ecryptfs: fill_keyring: Passphrase file wrapped login: LOGIN ON tty3 BY alice ------- Executing "ecrypt.sh alice" and "setsebool -P use_ecryptfs_home_dirs 1" did not help, the home directory is still not mounted. (Btw, what is "Step 1" in comment #17 supposed to be? Looks like an awk script?) I'll attach the entries from audit.log. Created attachment 589308 [details]
audit.log & more
What's the time plan for this bug fix? This bug was reported two fedora releases ago and I'm getting more and more complaints about not working ecryptfs encryption. Is there a plan to fix this soon or should I modify home encryption tool to tell users to disable selinux to get it working? Yes, a policy fix is going to be part of F17 soon. Created attachment 589515 [details] Fix selinux to allow ecryptfs-migrate-home I have successfully used the attached script on two F17 installations. After running it home directories can be migrated using ecryptfs-migrate-home without problems. Selinux can be in enforcing mode all the time. After having dealt with the Selinux errors I occasionally experienced that I could log in but file names were still encrypted. It is probably caused by Bug 754703. A work-around is included at the end of the script. > After having dealt with the Selinux errors I occasionally experienced that I
> could log in but file names were still encrypted. It is probably caused by
> Bug 754703. A work-around is included at the end of the script.
Yes, it's caused with ecryptfs module not loaded in advance. Scripts (and binaries) used several workarounds for this, but with more and more strict policy, all of them stopped working properly. I've build new packages yesterday and I'm testing them right now. It was working for me and because you've confirmed it works in your case too, I'm going to push it to updates-testing.
(In reply to comment #23) > > ...Is there a plan to fix this soon or should I modify > > home encryption tool to tell users to disable selinux to get it working? > (In reply to comment #24) > Yes, a policy fix is going to be part of F17 soon. any time soon? Fixed in selinux-policy-3.10.0-139.fc17 (In reply to comment #28) > Fixed in selinux-policy-3.10.0-139.fc17 are any changes (selinux boolean or something) required in ecryptfs-utils? (In reply to comment #29) > (In reply to comment #28) > > Fixed in selinux-policy-3.10.0-139.fc17 > > are any changes (selinux boolean or something) required in ecryptfs-utils? Yes. # the ecryptfs-migrate-home script needs to be patched using # restorecon -R -v $HOME/$USER # semanage fcontext -a -e /home /home/.ecryptfs # restorecon -R -v $HOME/.ecrypfs/$USER and turn on the boolean. selinux-policy-3.10.0-140.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-140.fc17 Package selinux-policy-3.10.0-140.fc17: * should fix your issue, * was pushed to the Fedora 17 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.10.0-140.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10840/selinux-policy-3.10.0-140.fc17 then log in and leave karma (feedback). selinux-policy-3.10.0-140.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. I've applied the selinux-policy update and I'm now trying to update my existing install so I can re-enable selinux. I've performed the first three steps. Could you confirm the fourth is: setsebool -P use_ecryptfs_home_dirs 1 (In reply to comment #30) > > Yes. > > # the ecryptfs-migrate-home script needs to be patched using > > # restorecon -R -v $HOME/$USER > # semanage fcontext -a -e /home /home/.ecryptfs > # restorecon -R -v $HOME/.ecrypfs/$USER > > and turn on the boolean. Thanks. Yes. Also execute # restorecon -R -v /home to make sure all labeling is ok. (In reply to comment #35) > Yes. Also execute > # restorecon -R -v /home > to make sure all labeling is ok. Thanks! These instructions, in combination with the policy update, work for me and I now have selinux enforcing with ecryptfs home directories. Great. Thank you for testing. I am currently testing F-20 (alpha + latest updates), and the bug described over here has reemerged: I have to run the following to get my ecrypfs home to automount again: # restorecon -R -v $HOME/$USER # semanage fcontext -a -e /home /home/.ecryptfs # restorecon -R -v $HOME/.ecrypfs/$USER and turn on the boolean. What AVC are you getting? Do you need more than that? type=AVC msg=audit(1383733368.264:584): avc: denied { getattr } for pid=3271 comm="gdm-session-wor" path="/home/.ecryptfs/dominik/.ecryptfs/auto-umount" dev="sdb1" ino=32112646 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file type=SYSCALL msg=audit(1383733368.264:584): arch=x86_64 syscall=stat success=no exit=EACCES a0=7f768b022a50 a1=7fff2adc9a00 a2=7fff2adc9a00 a3=7f767ef557f8 items=0 ppid=3012 pid=3271 auid=1000 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 ses=5 tty=(none) comm=gdm-session-wor exe=/usr/libexec/gdm-session-worker subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Strange. Does $ restorecon -R -v /home/.ecryptfs/dominik fix the labeling? Sorry for answering late... At the time $ restorecon -R -v /home/.ecryptfs/dominik fixed the labeling. Sorry, why is this NOTABUG? Shouldn't at keast ecryptfs-migrate-home be fixed such that restorecon is run automatically? How are users supposed to know that this manual step is necessary? Any movement on this? There must be some different problem because ecrypts-migrate-home does call restorecon. ... restorecon -R /home/.ecryptfs/$USER_NAME >/dev/null 2>&1 ||: umount "$USER_HOME/" restorecon -R "$USER_HOME" >/dev/null 2>&1 ||: so both /home/.ecryptfs/<username> and /home/<username> should have correct selinux context. Is it still reproducible? Before ecryptfs-migrate-home, files in the users home dir have type user_home_t. Afterwards, they have ecryptfs_t. Running restorecon changes nothing. Is that the expected / correct behavior? I would have expected user_home_t after the migration... But I didn't notice any errors or AVC denials in the procedure below. [ ~]# rpm -q ecryptfs-utils ecryptfs-utils-103-4.fc20.x86_64 [ ~]# rpm -q selinux-policy-targeted selinux-policy-targeted-3.12.1-196.fc20.noarch [ ~]# getenforce Enforcing [ ~]# useradd -m seppel [ ~]# passwd seppel passwd: all authentication tokens updated successfully. [ ~]# ls -aZ /home/seppel/ drwx------. seppel seppel unconfined_u:object_r:user_home_dir_t:s0 . drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. -rw-r--r--. seppel seppel unconfined_u:object_r:user_home_t:s0 .bash_logout -rw-r--r--. seppel seppel unconfined_u:object_r:user_home_t:s0 .bash_profile [ ~]# usermod -a -G ecryptfs seppel [ ~]# ecryptfs-migrate-home -u seppel 1. The file encryption appears to have completed successfully, however, seppel MUST LOGIN IMMEDIATELY, _BEFORE_THE_NEXT_REBOOT_, TO COMPLETE THE MIGRATION!!! (seppel logs in on another terminal, success) [ ~]# ls -aZ /home/seppel drwx------. seppel seppel system_u:object_r:ecryptfs_t:s0 . drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. -rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0 .bash_logout -rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0 .bash_profile -rw-r--r--. seppel seppel system_u:object_r:ecryptfs_t:s0 .bashrc lrwxrwxrwx. seppel seppel system_u:object_r:ecryptfs_t:s0 .ecryptfs -> /home/.ecryptfs/seppel/.ecryptfs ... [ ~]# ls -aZ /home/.ecryptfs/seppel/ drwxr-xr-x. seppel seppel unconfined_u:object_r:user_home_dir_t:s0 . drwxr-xr-x. root root unconfined_u:object_r:home_root_t:s0 .. drwx------. seppel seppel unconfined_u:object_r:ecryptfs_t:s0 .ecryptfs drwx------. seppel seppel unconfined_u:object_r:ecryptfs_t:s0 .Private This seems to work now on Fedora 21, although a few warnings remain: ============================================================================ # yum install ecryptfs-utils lsof # useradd testuser && passwd testuser # ls -laZ ~testuser/ drwx------. testuser testuser unconfined_u:object_r:user_home_dir_t:s0 . drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. -rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_logout -rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_profile -rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bashrc # usermod -G ecryptfs testuser # ecryptfs-migrate-home -u testuser INFO: Checking disk space, this may take a few moments. Please be patient. INFO: Checking for open files in /home/testuser Enter your login passphrase [testuser]: ************************************************************************ YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION. ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME. ************************************************************************ /usr/sbin/restorecon /usr/sbin/restorecon Done configuring. chown: cannot access ‘/dev/shm/.ecryptfs-testuser’: No such file or directory INFO: Encrypted home has been set up, encrypting files now...this may take a while. sending incremental file list ./ .bash_logout .bash_profile .bashrc Could not unlink the key(s) from your keying. Please use `keyctl unlink` if you wish to remove the key(s). Proceeding with umount. .... # ssh localhost -l testuser testuser@localhost's password: testuser@fedora0:/home/testuser$ df -h . Filesystem Size Used Avail Use% Mounted on /home/testuser/.Private 3.7G 1.9G 1.5G 57% /home/testuser testuser@fedora0:/home/testuser$ ls -laZ drwx------. testuser testuser system_u:object_r:ecryptfs_t:s0 . drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. -rw-------. testuser testuser system_u:object_r:ecryptfs_t:s0 .bash_history -rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0 .bash_logout -rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0 .bash_profile -rw-r--r--. testuser testuser system_u:object_r:ecryptfs_t:s0 .bashrc lrwxrwxrwx. testuser testuser system_u:object_r:ecryptfs_t:s0 .ecryptfs -> /home/.ecryptfs/testuser/.ecryptfs lrwxrwxrwx. testuser testuser system_u:object_r:ecryptfs_t:s0 .Private -> /home/.ecryptfs/testuser/.Private ============================================================================ No SELinux warnings were recorded, yay :) Of course, now I get an error in syslog when a non-ecryptfs-enabled user (e.g. "root") is logging in to the system: Mar 03 18:43:52 fedora0. sshd[1597]: pam_unix(sshd:session): session opened for user root by (uid=0) Mar 03 18:43:52 fedora0 sshd[1597]: ecryptfs: fill_keyring: Unable to get ecryptfs pam data : No module specific data is present ...but that may be material for another bug report. |