Description of problem: After upgrading selinux-policy gnome-login can't mount ecryptfs home directory. Workarround: Setting selinux to permisive. SELinux is preventing (systemd) from read, open access on the file /usr/sbin/mount.ecryptfs_private. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that (systemd) should be allowed read open access on the mount.ecryptfs_private file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '(systemd)' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:mount_ecryptfs_exec_t:s0 Target Objects /usr/sbin/mount.ecryptfs_private [ file ] Source (systemd) Source Path (systemd) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages ecryptfs-utils-111-22.fc34.x86_64 SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.12.17-300.fc34.x86_64 #1 SMP Wed Jul 14 19:39:03 UTC 2021 x86_64 x86_64 Alert Count 7 First Seen 2021-07-21 11:24:23 CEST Last Seen 2021-07-22 07:38:12 CEST Local ID d81b256d-0c3c-4f10-bc56-a8250d8661a4 Raw Audit Messages type=AVC msg=audit(1626932292.593:826): avc: denied { read open } for pid=1748 comm="(systemd)" path="/usr/sbin/mount.ecryptfs_private" dev="dm-0" ino=2510137 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount_ecryptfs_exec_t:s0 tclass=file permissive=1 Hash: (systemd),init_t,mount_ecryptfs_exec_t,file,read,open Version-Release number of selected component: selinux-policy-targeted-34.14-1.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.15.2 hashmarkername: setroubleshoot kernel: 5.12.17-300.fc34.x86_64 type: libreport Potential duplicate: bug 1609474
I have the same problem. Changing selinux into "permissive" mode fixes this. selinux-policy-34.14-1.fc34.noarch selinux-policy-targeted-34.14-1.fc34.noarch ecryptfs-utils-111-22.fc34.x86_64 kernel-5.13.4-200.fc34.x86_64
Mounting "~/Private" after login works in SELinux enforcing mode with `ecryptfs-mount-private`. Changing SELinux mode for this session: $ getenforce $ sudo setenforce permissive ... permanently: $ sudo nano /etc/selinux/config change from: SELINUX=enforcing to: SELINUX=permissive $ sudo reboot
Confirmed for another F34 install here, and setting selinux to permissive as a workaround. This applies to all login modes (gdm, ssh, etc.). To be clear: this bug prevents mounting of home directories for all users on setups using ecryptfs. For less technical users this manifested as their systems automatically but mysteriously becoming thoroughly broken about 2 weeks ago (17 July) -- although login appears to succeed and the desktop appears, settings for firefox/thunderbird/anything aren't accessible etc. so applications don't work correctly. selinux-policy-34.14-1.fc34.noarch selinux-policy-targeted-34.14-1.fc34.noarch ecryptfs-utils-111-22.fc34.x86_64 kernel-5.13.5-200.fc34.x86_64
This is how to set up eCryptfs-powered "~/Private" on Fedora 34: ## preparation $ sudo dnf install -y ecryptfs-utils $ sudo usermod -aG ecryptfs YOURACCOUNT $ sudo reboot ## configuration YOURACCOUNT$ ecryptfs-setup-private - type your login password and press enter - press enter to generate mount passphrase - ~/Private and ~/.Private and ~/.ecryptfs are created - ~/Private contains "Access-Your-Private-Data.desktop" and "README.txt" and is not writeable if not mounted - log out ### usage - log in with YOURACCOUNT at GDM login screen - ~/Private should get mounted automatically and be writeable
Automatic mounting of eCryptfs "~/Private" worked on Fedora 32. Also on Fedora 34 with: selinux-policy-34.3-1.fc34.noarch selinux-policy-targeted-34.3-1.fc34.noarch But does not get mounted since: selinux-policy-34.14-1.fc34.noarch selinux-policy-targeted-34.14-1.fc34.noarch Problem still present with Fedora 36 (branched), hence I filed an upstream bug report: https://github.com/fedora-selinux/selinux-policy/issues/1103
My current findings wrap-up: F35 - selinux-policy-35.15-1.fc35.noarch ecryptfs-utils-111-24.fc35.x86_64 F36 - selinux-policy-36.4-1.fc36.noarch ecryptfs-utils-111-26.fc36.x86_64 ecryptfs-mount-private works, automounting not neither in SELinux enforcing nor permissive There are some rules which should be added in selinux-policy: # cat local_crypt.cil (allow unconfined_t mount_ecryptfs_exec_t (file (entrypoint))) (allow mount_ecryptfs_t fs_t (filesystem (getattr))) (allow init_t mount_ecryptfs_exec_t (file (execute open read))) # semodule -i local_crypt.cil After this, no AVCs are audited, but the result keeps the same. So I don't think the only problem is in selinux-policy. Can you help with further troubleshooting? I probably don't completely understand how it works. I can see there is home-cryptuser-Private.mount unit.
I tested with a virtual machine with Fedora Workstation 36 installed with netinstall ISO file. Automounting works for me with the above guide, SELinux permissive mode, and these packages: $ rpm -q selinux-policy ecryptfs-utils selinux-policy-36.3-1.fc36.noarch ecryptfs-utils-111-26.fc36.x86_64 To match your environment: - I updated: $ sudo dnf install -y https://kojipkgs.fedoraproject.org//packages/selinux-policy/36.4/1.fc36/noarch/selinux-policy-36.4-1.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/selinux-policy/36.4/1.fc36/noarch/selinux-policy-targeted-36.4-1.fc36.noarch.rpm - set SELinux enforcing mode - reboot - log in; automounting does not work - created "local_crypt.cil" file with give content and executed `semodule -i local_crypt.cil` - reboot - log in; automounting works I will help. 1. eCryptFS PAM support is required for automounting to work. Do you see "with-ecryptfs" in the following command too? Output for me is: $ authselect current Profile ID: sssd Enabled features: - with-fingerprint - with-silent-lastlog - with-ecryptfs - with-mdns4 If it is missing, run `sudo authselect enable-feature with-ecryptfs` and reboot. In my working eCryptFS-Private environment I removed the feature with `sudo authselect disable-feature with-ecryptfs`, rebooted, and encountered your described situation. 2. I have no "home-cryptuser-Private.mount". What is the absolute path? Which package provides it (`rpm -qf <absolute path>`)? 3. If the above does not help, describe your steps. Start at the download of the ISO file for Fedora installation.
When pam is configured: https://wiki.archlinux.org/title/ECryptfs#Auto-mounting it starts to work. If you wish, you can try the F36 testing package: https://github.com/fedora-selinux/selinux-policy/pull/1105 Checks -> Details -> Artifacts -> rpms It should also be a part of the next build.
*** Bug 2009954 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #8) > When pam is configured: > https://wiki.archlinux.org/title/ECryptfs#Auto-mounting > > it starts to work. If you wish, you can try the F36 testing package: > > https://github.com/fedora-selinux/selinux-policy/pull/1105 Tested on Fedora 36. It fixes the problem for me. Thank you!
*** Bug 1997457 has been marked as a duplicate of this bug. ***
FEDORA-2022-9e53cb5027 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e53cb5027
FEDORA-2022-9e53cb5027 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-9e53cb5027` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e53cb5027 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-9e53cb5027 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.