Bug 1701347

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.