]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
update TODO 30226/head
authorLennart Poettering <lennart@poettering.net>
Mon, 27 Nov 2023 14:09:05 +0000 (15:09 +0100)
committerLennart Poettering <lennart@poettering.net>
Wed, 14 Feb 2024 14:10:39 +0000 (15:10 +0100)
TODO

diff --git a/TODO b/TODO
index c0260c7b037538756348841a78d53a78278d2400..a64a6a0c1c29adc03dcaa9ea4d3c44736532cb52 100644 (file)
--- a/TODO
+++ b/TODO
@@ -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