Allow running scripts on success/failure of sign in

[plan5]

Is your feature request related to a problem? Please describe.
A recent post on reddit announced a gocryptfs frontend that en-/decrypts /home/root.
With encryption in place and the directory decrypted, the lockscreen will be the barrier that protects the data from unauthorized access. A four digit PIN is weak for sensitive data.

Describe the solution you'd like
Implement a forced reboot after a defined number of failed unlock attempts. This will unmount the encrypted drive.
Additionally, it will add a delay that slows down automized password guessing.

Describe alternatives you've considered
Instead of a reboot, the command to be run could be configurable. e.g. it could also simply unmount a defined directory.

Additional context
The reddit post about an encryption UI is here:
https://www.reddit.com/r/RemarkableTablet/comments/lva2er/bringing_strong_encryption_to_the_remarkable_2/

gocryptfs ist here (builds easily on the rM with go installed):
https://github.com/rfjakob/gocryptfs

More additional context
I wrote a hacky simple-sas script that does the same. Not very reliable, I assume.
It's here: http://ix.io/2RAo
The script runs no checks and only has a rather limited set of characters currently.
It assumes that gocryptfs is installed as /home/root/go/bin and that fuse-utils is installed from toltec.
/home/root/.local/share/remarkable must be empty,
/home/root/.local/share/remarkable-cipher is the location of encrypted data (created with gocryptfs -init).

[Eeems]

I'm not sure I want to support this out of box. What I would be willing to do would be to allow the lockscreen to run custom scripts on failure and success. Would that address your need?

[plan5]

That would be a perfect solution!

[Eeems]

@plan5 Another thing to note, if you would like to use a custom lock screen (like your script) you can change the lockscreen that tarnish will launch by registering your application (preferably with an *.oxide file) and then setting it as the lockscreen application:

rot apps set lockscreenApplication $application_path

Where $application_path is the path returned for the application when you find it's entry in the output of rot apps get applications

[Eeems]

Alright, so implementation details, ~/.config/Eeems/decay.conf will now allow for two new settings.

• onLogin - Path to script/binary to run when the user logs in.
• onFailedLogin - Path to the script/binary to run when there is a failed login attempt.

These paths should ideally be absolute paths. Ideally these scripts/binaries should finish execution as quick as possible as further execution is paused waiting for them.

Example:

reMarkable: ~/.config/Eeems/ cat onlogin.sh 
#!/bin/bash
echo "Login!"
date +%s > /tmp/lastlogin
echo 0 > /tmp/failedattemptcount
reMarkable: ~/.config/Eeems/ cat onfailedlogin.sh 
#!/bin/bash
echo "Failed login!"
date +%s > /tmp/lastfailedattempt
count="$(cat /tmp/failedattemptcount)"
echo "$((count + 1))" > /tmp/failedattemptcount
reMarkable: ~/.config/Eeems/ cat decay.conf 
[General]
pin=1234
onLogin=/home/root/.config/Eeems/onlogin.sh
onFailedLogin=/home/root/.config/Eeems/onfailedlogin.sh
version=1

This will result in /tmp/failedattemptcount containing the number of failures, /tmp/lastfailedattempt containing the timestamp of the last failed attempt, and /tmp/lastlogin containing the timestamp of the last successful login.

[plan5]

That's awesome, thanks!

Closing the issue, all wishes fulfilled :)

(Hope you didn't want to keep it open until release)

[Eeems]

(Hope you didn't want to keep it open until release)

🤷‍♂️ I kind of close them when the changes get to master, but not before the release is actually out. So whatever :)

[Eeems]

@plan5 fyi the next release will be moving these settings to ~/.config/Eeems/shared.conf under [Lockscreen] as part of #293

They will be auto migrated for any existing values, but you'll be able to set them with xdg-settings in a script.