1
0
mirror of https://github.com/systemd/systemd synced 2024-07-08 20:15:55 +00:00

update TODO

This commit is contained in:
Lennart Poettering 2023-11-27 15:09:05 +01:00
parent 8349bbdfd8
commit 1c5d03c088

12
TODO
View File

@ -1195,16 +1195,8 @@ Features:
passwords, not just the first. i.e. if there are multiple defined, prefer
unlocked over locked and prefer non-empty over empty.
* homed: while a home dir is not activated generate slightly different NSS
records for it, that reports the home dir as "/" and the shell as some binary
provided by us. Then, when an SSH login happens and SSH permits it our binary
is invoked. This binary can then talk to homed and activate the homedir if
it's not around yet, prompting the user for a password. Once that succeeded
we'll switch to the real user record, i.e. home dir and shell, and our tool
exec()s the latter. Net effect: ssh'ing into a homed account will just work:
we'll neatly prompt for the homedir's password if its needed. Building on
this we could take this even further: since this tool will potentially have
access to the client's ssh-agent (if ssh-agent forwarding is enabled) we
* homed: if the homed shell fallback thing has access to an SSH agent, try to
use it to unlock home dir (if ssh-agent forwarding is enabled). We
could implement SSH unlocking of a homedir with that: when enrolling a new
ssh pubkey in a user record we'd ask the ssh-agent to sign some random value
with the privkey, then use that as luks key to unlock the home dir. Will not