# Any progress or experience with fscrypt?

## Goverp

I see there's an entry in bugizlla for an ebuild for fscrypt.

Any progress on this?  I'm interested in using fscrypt on my laptop, which is a non-vital resource (effectively a portable clone of my desktop).  I guess I could try the ebuild from Shiba's wip overlay.  I'd be using it with OpenRc rather than systemd, but reading the Arch wiki item on fscrypt, I don't think that's an issue.

One of the drawbacks is fscrypt's use of Go, I guess for the user interface, which seems to cause ludicrous source chains.  That seems a bit like the mess you get into if you try compiling a Java application from all the sources, or maybe I'm misunderstanding.  It seems that making fscrypt itself is much easier than making the Go compiler required by the ebuild.  The Arch PKGBUILD lists many fewer prereqs than the ebuild.

----------

## Goverp

OK, I've now installed and used the sys-fs/scrypt ebuild to build the fscrypt module mentioned above.  It needs dev-lang/go installed before it will build.

As I wanted to use my pam-login to decrypt my home folder on login, IIUC it needs all the pam.d changes in the Arch documentation at:

https://wiki.archlinux.org/index.php/Fscrypt#PAM_module

as well as the pam.d/fscrypt file created by the euilld.  (Arch seems to have cloned the Gentoo pam.d setup, which means it's easy to apply these changes.)

I enabled an encrypted home/user directory as per the documentation, and copied the contents of my old home into it.  Using sddm and KDE, I signed in to user, and yup, everything was unlocked - i.e. it appears decrypted to user programs such as ls, cat, KDE etc.  A bit surprisingly, files appeared decrypted to other users, such as root.  I didn't check, but I expect other members of the "users" group would be able to read the files now they were unlocked.  I don't think this is a bug; I've used a password to unlock the files, but it's a file-system-level unlock, not a user-level unlock, but working that way was unexpected.

Signing out from KDE did not lock the files.  That's due to KDE leaving files open; syslog messages.  I presume that's a bug.  The results are that other users could see the filenames, but not the contents.  After a reboot, the files were locked, and to all other users the file names and contents were encrypted.

As you might expect, "su user" from root does not unlock the files, as I'd not entered the password; signing into the user from a terminal session instead of KDE unlocked the files, and signing out locked them again, so the problem is definitely KDE.

I changed the user password using "passwd" from a terminal session.  That worked signing in with the new password unlocked the files - even after a reboot.  That doesn't change the file encryption or keys; the user password is used to unlock the encryption key (I presume the encryption key is held enciphered with a token derived from the user login password in this setup.  IIUC, you can set up alternative tokens so you can unlock the data even without the user password, should you need it.  That might be very sensible if you want to take unencrypted backups.)

----------

## pietinger

Goverp,

thanks a lot for sharing your experience with fscrypt. I am very interested in it (I am waiting now over half a year to have it in gentoo).

Have a good time,

Peter

----------

## Shibotto

 *Goverp wrote:*   

> The Arch PKGBUILD lists many fewer prereqs than the ebuild.

 

That's because Gentoo enforces network-sandbox during build, so every dependency that usually would be fetched by the go command needs to be listed and fetched in advance. Arch on the other hand lets it go on a rampage and do pretty much whatever it wants.

If you look at a Rust ebuild it will send chills down your spine  :Shocked: 

 *Goverp wrote:*   

> Signing out from KDE did not lock the files.

 

I haven't tried this method so I don't know if it actually works: if you are using elogind you can try setting KillUserProcesses or KillOnlyUsers in /etc/elogind/logind.conf to kill every processes when you log out, but beware that it will also kill screen and tmux sessions (look at "man 5 logind.conf"). If you decide to try it, make sure that in the session group of /etc/pam.d/system-login pam_fscrypt.so is listed before pam_elogind.so, because on session close the PAM stack is called in reverse order (so pam_elogind.so kills everything, then pam_fscrypt.so tries to lock the file).

----------

## Goverp

 *Shibotto wrote:*   

> ...
> 
>  *Goverp wrote:*   Signing out from KDE did not lock the files. 
> 
> I haven't tried this method so I don't know if it actually works: if you are using elogind you can try setting KillUserProcesses or KillOnlyUsers in /etc/elogind/logind.conf to kill every processes when you log out, but beware that it will also kill screen and tmux sessions (look at "man 5 logind.conf"). If you decide to try it, make sure that in the session group of /etc/pam.d/system-login pam_fscrypt.so is listed before pam_elogind.so, because on session close the PAM stack is called in reverse order (so pam_elogind.so kills everything, then pam_fscrypt.so tries to lock the file).

 

Thanks for the info.  Am I right in thinking the default systemd setup uses "KillUserProcesses=yes"?  In which case KDE is probably now assuming said abomination.  I'll give it a try, even though it stinks.

----------

## Goverp

Curiouser and curiouser.  Before logging out from KDE, and nothing even open, lsof lists over 11,000 files (WTF?) open for my logged in user.  After logout, 0.  I suspect that means the KillUserProcess fiddling will be ineffective.

Boot log contains:

```
kernel: [ 3405.819362] fscrypt: sda5: 39 inode(s) still busy after removing key with identifier 3f390990b1cbd1b430aca924a9328717, including ino 907090
```

but find / -inum 907090 returns zilch

A bit of searching through old boot logs for the same message gave me a list of inode to look at; some were cache items, others no longer exist.  Maybe it's a timing issue.

----------

