[systemd-devel] Creating a roaming USB home area using homectl

[Matthew Wardrop]

Thanks for your response, Lennart!

I've created the requisite public keys to /var/lib/systemd/home; but things
still aren't working. Based on issue
https://github.com/systemd/systemd/issues/15178 am I correct in
understanding that the key revocation warning also covers instances where
the identity has not been locally created (or is empty)? Is there a way to
"re-fixate" a home area (setting up group membership / etc) using homectl,
or do you need to manually create the appropriate "*.identity" file?

Best,
M

On Tue, 31 Mar 2020 at 07:21, Lennart Poettering <lennart at poettering.net>
wrote:

> On So, 08.03.20 22:07, Matthew Wardrop (mpwardrop at gmail.com) wrote:
>
> > Greetings all,
> >
> > When I heard news of systemd-homed I was excited, since it was my
> > understanding I'd be able to ferry only my external hard drive between
> home
> > and work during my bicycle commute, and be able to forget about user id
> > issues/etc. I tried to set it up, but must be missing something.
> >
> > On one machine I ran:
> > $ sudo homectl create mawardrop --storage=luks -G docker -G wheel -G
> input
> > --image-path=/dev/sdc --shell=/usr/bin/zsh
> > (where /dev/sdc was my external hard drive).
> >
> > Everything works well locally. I can log in, and out, and the luks image
> > successfully mounts and unmounts; but when I attempt to login in on a
> > different machine also configured with systemd-homed, I come across two
> > issues.
> >
> > 1) In order for `homectl list` to show my new home folder, I need to
> > restart the homed service after plugging in the hard drive. That means I
> > need to have it plugged in on machine boot, or log in as a different user
> > and restart the service, for it to show up in in the login manager.
>
> Hmm, this is a bug. This should just work... homed subscribes to udev
> events to see everything plugged in. Can you file a bug about this.
>
> > 2) Even once visible, it appears as "unfixated". Any operations on the
> home
> > area such as `authenticate` or `activate` result in the error: "Operation
> > on home mawardrop failed: Failed to execute operation: Key has been
> > revoked".
>
> homed doesn't allow just anyone to login. It signs user records with a
> cryptographic key, and only allows users signed by a key known locally
> to log in.
>
> This needs better documentation, but the essence is that homed uses
>
> a private key stored in /var/lib/systemd/home/local.private to sign
> records with, and accepts all records signed by public keys matching
> /var/lib/systemd/home/*.public. If you create a local user and
> /var/lib/systemd/home/local.private does not exist yet a new key is
> automatically generated and stored there, and its public key stored in
> /var/lib/systemd/home/local.public.
>
> This means, if you want users created on machine quux to be able to
> log into machine waldo, make sure to copy quux's
> /var/lib/systemd/home/local.public file to waldo, maybe into a file
> /var/lib/systemd/home/quux.public.
>
> > Am I just too early to the game, in that multi-machine setups are not yet
> > supported? Or is there something obvious I am missing?
>
> They are supported, just underdocumented ;-)
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200402/e8ee4b29/attachment.htm>