Description of problem: It is not possible to install ecryptfs-utils on SilverBlue 30 Version-Release number of selected component (if applicable): Silverblue 30. How reproducible: Every time Steps to Reproduce: 1. Install Fedora Silverblue 30 2. Run the following command after installation: rpm-ostree install ecryptfs-utils 3. Installation will fail Actual results: $ rpm-ostree install ecryptfs-utils Checking out tree 55a3261... done Enabled rpm-md repositories: fedora updates updates-testing rpm-md repo 'fedora' (cached); generated: 2019-04-16T10:05:31Z rpm-md repo 'updates' (cached); generated: 2018-02-20T19:18:14Z rpm-md repo 'updates-testing' (cached); generated: 2019-04-17T14:10:07Z Importing rpm-md... done Resolving dependencies... done Checking out packages... done Running pre scripts... done Running post scripts... done error: Running %post for ecryptfs-utils: Executing bwrap(/bin/sh): Child process killed by signal 2; run `journalctl -t 'rpm-ostree(ecryptfs-utils.post)'` for more information $ Expected results: Installation to complete without error Additional info: journalctl -t 'rpm-ostree(ecryptfs-utils.post)' command returns "-- No entries --" output. Same issue regardless of sudo being used or not. I also tested installation with chromium, which completed without issue.
I managed to get the package to install and it is showing in rpm-ostree: $ rpm-ostree status State: busy AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot Transaction: refresh-md Deployments: ● ostree://fedora-workstation:fedora/30/x86_64/silverblue Version: 30.20190418.n.0 (2019-04-18T08:58:25Z) BaseCommit: 55a326180f2950af25017db52256e19bfeefc54b273126f27dda462e74906408 GPGSignature: Valid signature by F1D8EC98F241AAF20DF69420EF3C111FCFC659B9 LayeredPackages: rpmrebuild LocalPackages: ecryptfs-utils-111-17.fc30.x86_64 ostree://fedora-workstation:fedora/30/x86_64/silverblue Version: 30.20190418.n.0 (2019-04-18T08:58:25Z) BaseCommit: 55a326180f2950af25017db52256e19bfeefc54b273126f27dda462e74906408 GPGSignature: Valid signature by F1D8EC98F241AAF20DF69420EF3C111FCFC659B9 LayeredPackages: rpmrebuild I used rpmrebuild to remove the postinstall script, which is the part which was failing. Unfortunately that part of the RPM is required, and runs the following command: authselect enable-feature with-ecryptfs. Not wholly unexpected. When attempting to run ecryptfs-migrate-home without it, an error is returned with instructions to run authselect: $ sudo ecryptfs-migrate-home -u $USER ERROR: You must enable ecryptfs pam module first. It can be enabled by using: authselect enable-feature with-ecryptfs Running authselect fails: $ sudo authselect enable-feature with-ecryptfs Unable to enable feature [2]: No such file or directory On a regular non-silverblue Fedora 30 installation, this works without issues. So it's actually some interaction between authselect and silverblue which is the culprit here, not ecryptfs-utils. I shall adjust the bug entry accordingly.
Created attachment 1556894 [details] strace output of authselect enable-feature with-ecryptfs command This is the output from strace of me running the authselect enable-feature with-ecryptfs command.
I think that Silverblue PAM configuration was not created with authselect (vanilla Fedora calls authselect during anaconda installation). To confirm, please tell me what is the output of 'sudo authselect current'?
(In reply to Pavel Březina from comment #3) > To confirm, please tell me what is the output of 'sudo authselect current'? Output as below: $ sudo authselect current No existing configuration detected.
Thank you. The problem is that Silverblue did not use authselect to configure PAM, but scriptlets in ecryptfs-utils cannot cope with this situation. %post /sbin/ldconfig if [ $1 -eq 1 ] ; then # Initial installation authselect enable-feature with-ecryptfs >/dev/null 2>&1 fi %postun /sbin/ldconfig if [ $1 -eq 0 ] ; then # Package removal, not upgrade authselect disable-feature with-ecryptfs >/dev/null 2>&1 fi The scriptlets should deal with it somehow. Perhaps return 0 and let the user configure it manually if authselect command fails. I'm changing the component to ecrypfs-utils as it needs to be addressed here.
I have gotten ecryptfs working on Silverblue (rawhide), though it required some somewhat janky hacks. First, you must configure PAM to use ecryptfs. You can do this by running `sudo authselect select sssd with-ecryptfs --force`. This will clobber the nsswitch config Silverblue uses, so after you've done this (before rebooting!) you must edit the following /etc/nsswitch.conf lines: passwd: sss files systemd group: sss files systemd back to their original: passwd: sss files altfiles systemd group: sss files altfiles systemd This will make authselect quite upset on any future runs (since it has no understanding of altfiles), but that's okay since you're not likely to need to run it again on a personal device. I attempted keeping the altfiles bit removed to instead use sssd's alternative files domain (as described in https://github.com/pbrezina/authselect/issues/48#issuecomment-384973785), but even pointing that at /usr/lib/{passwd,group} led to an unbootable system. Once you've done this and rebooted to make sure everything still works, you'll want download the ecryptfs-utils rpm manually and use `rpmrebuild` on it to edit the spec file. You should remove the two %post entries referencing authselect (since you've configured everything yourself) and change the permissions on `mount.ecryptfs_private` to be 4755 root:root instead of 4750 root:ecryptfs (if you leave the permissions as is and instead add yourself to the ecryptfs with /etc/group as you'd normally do with ecryptfs, things will appear to work but rpm-ostree will throw errors about not being able to find the group next time you try to do any operation). You can then rpm-ostree install the modified rpm and everything should work. Hopefully this will all become unnecessary in the future once this is resolved: https://github.com/coreos/rpm-ostree/issues/49
You can also use 'authselect select sssd with-ecryptfs with-custom-passwd with-custom-group' which will keep the current passwd and group setting in nsswitch.conf. About using sssd -- perhaps silverblue needs to resolve the users before sssd is running?
(In reply to Pavel Březina from comment #7) > You can also use 'authselect select sssd with-ecryptfs with-custom-passwd > with-custom-group' which will keep the current passwd and group setting in > nsswitch.conf. This does not actually seem to work? plailect@tao ~ $ sudo authselect select sssd with-ecryptfs with-custom-passwd with-custom-group [error] [/etc/authselect/nsswitch.conf] has unexpected content! [error] Unexpected changes to the configuration were detected. [error] Refusing to activate profile unless those changes are removed or overwrite is requested. Some unexpected changes to the configuration were detected. Use --force parameter if you want to overwrite these changes. > About using sssd -- perhaps silverblue needs to resolve the users before > sssd is running? I don't believe this it the case, though I am not certain. When I looked at the logs SSSD's service had started very early (with logs indicating normal activity as far as I could tell), but i.e.: gdm refused to start at the very end of boot due to the gdm user not being found.
(In reply to Devon Maloney from comment #8) > (In reply to Pavel Březina from comment #7) > > You can also use 'authselect select sssd with-ecryptfs with-custom-passwd > > with-custom-group' which will keep the current passwd and group setting in > > nsswitch.conf. > > This does not actually seem to work? > > plailect@tao ~ $ sudo authselect select sssd with-ecryptfs > with-custom-passwd with-custom-group > [error] [/etc/authselect/nsswitch.conf] has unexpected content! > [error] Unexpected changes to the configuration were detected. > [error] Refusing to activate profile unless those changes are removed or > overwrite is requested. > > Some unexpected changes to the configuration were detected. > Use --force parameter if you want to overwrite these changes. Since you modified nsswitch.conf manually you need to use --force. Also make sure that the settings you need (altfiles) is in /etc/authselect/user-nsswitch.conf. > > About using sssd -- perhaps silverblue needs to resolve the users before > > sssd is running? > > I don't believe this it the case, though I am not certain. When I looked at > the logs SSSD's service had started very early (with logs indicating normal > activity as far as I could tell), but i.e.: gdm refused to start at the very > end of boot due to the gdm user not being found.
(In reply to Devon Maloney from comment #8) > > About using sssd -- perhaps silverblue needs to resolve the users before > > sssd is running? > > I don't believe this it the case, though I am not certain. When I looked at > the logs SSSD's service had started very early (with logs indicating normal > activity as far as I could tell), but i.e.: gdm refused to start at the very > end of boot due to the gdm user not being found. Can you attach SSSD's logs and sssd.conf?
(In reply to Pavel Březina from comment #9) > Since you modified nsswitch.conf manually you need to use --force. Also make > sure that the settings you need (altfiles) is in > /etc/authselect/user-nsswitch.conf. Ah. Yes, this seems to have worked, though with a new and interesting bug. For some reason on silverblue f32 (rawhide), authselect select (and authselect enable-feature) seems to cause gnome to core dump? It did not do this a week ago so that's fun.... (In reply to Pavel Březina from comment #10) > Can you attach SSSD's logs and sssd.conf? I do not have the logs anymore, though the config was this: [sssd] config_file_version = 2 services = nss, pam domains = files [domain/files] id_provider = files passwd_files = /etc/passwd, /usr/lib/passwd group_files = /etc/group, /usr/lib/group
Authselect has not changed for a long time now but it calls dconf internally so perhaps this tool somehow triggers the crash. Please, report it against gnome.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.