On Mon, Oct 7, 2024, at 7:12 AM, Lennart Poettering wrote: > On Fr, 04.10.24 11:20, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > >> > The primary purpose of systemd-homed is to use per-user encryption >> > using loopback devices. This still has various problem related to >> > resizing and suspend. Work is being done [see 3,4 for recent developments], >> > but it's not at a point where we can recommend it. >> > But systemd-homed has a mode where the user "home" is just a normal >> > directory or btrfs subvolume with some metadata stored in files [5]. >> > Some work would be needed [6] to make this work smoothly, but it >> > doesn't seem like too much. (Mostly filing down some rough edges >> > in systemd-homed and adding pam_home_systemd and nss_systemd >> > in various authselect profiles.) >> > >> > Thus the question: would this be something worth looking into? >> >> When this was first explored a few years ago, the main problem that >> came up was that homed is functionally incompatible with centralized >> login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, >> then it would make sense to revisit. > > Well, you are comparing apples and oranges here. sssd/freeipa provides > some users to the system, as does the traditional /etc/passwd system, > and now homed some more. > > You should be able to combine the three sources of users freely > without problems – if you like. But these three sources of user > definitions should be on similar footing, and not try to abstract each > other. > > Hence: if you have some user in ldap/ipa, and another in homed, that's > entirely fine, they should not affect each other. Supporting local encrypted user data with centralized authentication methods is desired. Why implement this outside of systemd-homed rather than within it? The former seems like a duplicated effort. But OK, I don't know how the sd-homed key eviction feature at sleep time might work for centralized authentication. -- Chris Murphy -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
