Howdy: login loops if home directory is encrypted

[ANDROID2468]

_Please describe the issue in as much detail as possible, including any errors and traces_
On initial boot, if you try to login with your face, it will loop. but you can still unlock it after the first login and if you log out and log back in it will work.
But I shud also mention that I encrypted my home directory after I installed ubuntu.

---

I've searched for similar issues already, and my issue has not been reported yet.

Linux distribution (if applicable):ubuntu 19.04

Howdy version: latest

[boltgolt]

I highly doubt that the encrypted home directory is to blame, as nothing in Howdy has anything to do with /home. Are there any errors in /var/log/auth.log when it loops?

[ANDROID2468]

I did more testing on this. since I reported this bug, I did switch distros (switch to pop os) which is still based on Ubuntu. so I made a new user to test this issue and I encrypted the home directory then I add a face to the user and found out that it works! but then I found out if you added a face before you encrypt your home directory than the login loops.
I looked through the log and I found this:

May 11 09:08:59 pop-os systemd-logind[854]: New session 2 of user nicholas.
May 11 09:08:59 pop-os systemd: pam_unix(systemd-user:session): session opened for user nicholas by (uid=0)
May 11 09:09:01 pop-os gdm-password]: pam_unix(gdm-password:session): session closed for user nicholas
May 11 09:09:01 pop-os systemd-logind[854]: Session 2 logged out. Waiting for processes to exit.
May 11 09:09:01 pop-os systemd-logind[854]: Removed session 2.
May 11 09:09:05 pop-os gdm-password]: gkr-pam: no password is available for user

[ANDROID2468]

update: the test user I made to test this issue is now broken too. so no matter if you add a face before or after you encrypt your home directory, it will still brake. I did not use LUKS encryption. I forgot to mention that.

[berndso]

I do not think this issue is dependent on the linux distribution. I have the exact same symptoms with a Manjaro + gnome installation where i encrypted the home directory using ecryptfs-migrate-home.
The problem is that the home directory needs the actual login password to be mounted and decrypted on first boot. After mounting once, howdy works fine.
Fingerprint readers run into the same issues.

My ugly workaround is to cover the camera on first login, wait until face recognition fails and use my password for initial login.

An option to disable howdy on first boot would be much better, and also generally more secure. This would be similar android devices that require a pin/password once after reboot before they make use of the fingerprint/face unlock functionality.

Maybe this can already be accomplished by modifying the right pam config. like here
but i could not make this work for howdy and gdm so far.

the only file i edited to get howdy to work after the encrypet directory is mounted is /etc/pam.d/system-local-login .

[ANDROID2468]

@berndso I think the best thing to use if you want encryption is using LUKS for your home partition, which requires you to input a password to finish booting, enable Auto login so you don't have to type your pw twice, and disable keyring because it will complain at boot and your whole home partition is encrypted so keyring is pointless.
So now you can just use it to unlock it after you put your computer to sleep and for authentication. This way is probably the best way to do this and it cancels out the security risk of using face authentication.

[berndso]

@ANDROID2468 I aggree 100%, for most use cases this would absolutely be the best way to do it. However I am running kind of an edge case here, since i am using a tablet/hybrid and wanted to be able to unlock with the onscreen keyboard after reboot. As far as i know plymouth which is used for the LUKS passphrase at boot time does not support touch. Using ecryptfs seemed to be an elegant way around that.

[boltgolt]

Although i would like to keep Howdy as platform-neutral as possible (Howdy does not even know _why_ it is called), i agree that detecting and ignoring the first login would be the best fix. This has been requested before but preventing a login loop is a better reason to break neutrality than adding a feature for the sake of adding features.

I'm not sure how to reliably implement this though, what would be the best way to detect the authentication request is made by the first login screen?

[berndso]

Since the boot loop is only happening because the encrypted /home partition can not be mounted without a typed password, disabling howdy until home is mounted at the first login should work for this scenario.
However, as @ANDROID2468 stated this can also be avoided by having home encrypted via LUKS/dm-crypt. As a matter of fact, I now also switched to full disk encryption setup and grub even handles touch events and provides an on screen keyboard for my niche use case of having a tablet, so i am more than happy now :)

[persefone7]

Hi
Just to say I've just had a similar problem and after trying many things with no success, the solution seemed absurdly simple in my case so posting here in case it helps others.

I searched and tried various solutions, none worked.
Then found something about ecryptfs-mount-private. I tried to install it, found I didn't have enough space. So did sudo apt-get clean then installed again. When I tried to run it, it said the directory wasn't properly mounted so failed. However, I then tried to log in again and it worked this time. So, it seems that in my case, the sudo apt-get clean did the trick.

I don't know enough about the inner workings of the system, but maybe I had insufficient space to boot.

So, in summary

At boot screen, CTRL ALT f1 to get terminal

In terminal $ sudo apt-get clean

Then CTRL ALT F7 to get back to log-in screen

[krsch]

This issue could be fixed by checking some file or directory like $HOME/.config/ or $HOME/.Xauthority. This should be relatively easy to implement. I can try to make a PR but I don't know how to test it.