
Systemd-Homed: Systemd Now Working to Improve Home Directory Handling - protomyth
https://www.phoronix.com/scan.php?page=news_item&px=systemd-homed
======
andrerm
> So do I understand it correctly? The solution to SSH remote login is to not
> have it?

> With systemd-homed access to the home directory is simply impossible unless
> the luks keyphrase (aka "user password") is specified (i.e. tje user logged
> in) since the data store is after all fully encrypted unless the user logs
> in. Thats a good thing btw: the user's data should be protected from the
> system unless the user is actually logged in. Now, ssh public key auth
> doesnt deal with passwords hence just using ssh pk auth means we couldnt
> unlock the luks volume simply because we have no keyphrase to unlock things
> with. So the PAM module that unlocks homed volumes actually enquires the
> client for the password explicitly if this happens. Unfortunately this is
> not sufficient for this to work with openssh since its pam hook-up doesnt
> support asking questions via pam after authentication.

> That said people suggested we maybe should provide a stub account you can
> log into with a fixed password that instead of a shell just spawns a program
> that queries you for username and password and then allows you to unlock the
> specified home directory.

I get that GNU is not Unix but why do this guy hates Unix so much?

~~~
eikenberry
My guess is that this is not meant for systems you'd ssh into. That this
particular feature is designed specifically for use on laptops.

~~~
JohnFen
Huh? I ssh into my laptops all the time...

~~~
brmgb
It's only a problem if you want to use an encrypted home and ssh into your
laptop while not logged locally.

I mean, no one likes the current situation but it was deemed an acceptable
trade off considering there is a work around.

------
darren0
Systemd has always been hyper focused on the desktop/laptop experience, and
then justified for other use cases. Desktop is by a rediculously huge margin
the least important use case. So something like systemd-homed does not make
any sense in a server setup but I can basically guarantee it will be forced
upon server setups, just like systemd-resolvd was.

Ironically the very small percentage of users that use Linux on the desktop
tend to be of the more die-hard variety that don't welcome systemd's view of
the world.

In the end systemd is an extremely bad steward of Linux.

~~~
nightfly
My organization has been very happy with using systemd on servers. Having an
init system that can automatically restart failed services, and with decent
sdependency management is a big win. We've also been able to replace many
50-100 line long init scripts with systemd unit definitions that are 10 lines
long, and considerably more readable than the bash init scripts they replaced.
We've had some bad experiences too, logins being "slow" because something went
wrong and left 1000s of leftover session units in a weird state, systemd
vulnerabilities requiring reboots occasionally. But systemd has had a net-
positive impact.

~~~
cat199
nothing precludes a reasonable shell library from making initscripts 10 lines
long:

[http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1....](http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.6&content-
type=text/x-cvsweb-markup&only_with_tag=MAIN)

this does not require systemd cruft and all of it's over-opinionated facebook-
youth narcissistic my-use-case is all that matters tentacles.

~~~
theamk
Aren’t you replacing systemd with run_rc_command? This is just as opinionated,
but with less features.

(In particular, will the error be logged if the program fails to start due to
bad config file? And how do I describe “only start once “volume X” is
mounted?j)

~~~
cat199
> Aren’t you replacing systemd with run_rc_command? This is just as
> opinionated, but with less features.

sure, but this is a 'reasonable shell library' rather than the 'systemd cruft
+ tentacles' that I mention.

want it to do something else?

write your own functions.

want "an init system that can automatically restart failed services, and with
decent dependency management"

here you go:

    
    
        # cat /etc/daemoncheck
        #! /bin/sh
    
        docheck() {
            initscript="/etc/rc.d/$1";
            if [ -x "$initscript" ]; then
                $initscript check > /dev/null \
                    || $initscript start
            fi
        }
    
        docheck ntpd
        docheck inetd
        docheck dhcpd
        docheck tftpd
    

& throw that, or similar in cron or make it run in a while loop. Nothing
precludes some rudimentary shell script being bundled as part of a simple
shell-style init system out of the box.

I don't need 5000 lines of C code, multiple binaries, 10 layers of symlinks,
and all of the rest of it. a few hundred lines of shell that anyone who knows
shell and how to read manual pages (that are kept up to date on the actual
system, not bad HTML needing 10 tools to render the last time someone thought
to update the documentation) can understand the entierty of in literally one
sitting.

~~~
theamk
Thanks for the example -- because this is exactly why I am glad we had
systemd!

I do remember using the gentoo's rc system, and writing the script very much
like you wrote here, and it always "kinda works". Specifically, how is
"$initscript check" will work? I have seen three approaches:

\- Sometimes, "check" searches for the process with the given name. That can
fail if you are on multi-user system, and a user runs a server on non-standard
port.

\- Sometimes, "check" checks for .pid file, and that process with given pid
exists. This can fail if you have high process churn, and your PID got reused.

\- Sometimes, "check" does completely strange things. Like check that PID file
exists, but not the contents -- so it would work fine if you use start/stop
commands, but will not notice if the server crashes.

So yes, you can do it in shell, and it will work.. most of the time. And hey,
you can always fix it -- the first time you discover that your server did not
restart, you'd edit the script and add port checking... and then upgrade it to
better kill runaway processes.. you can keep going and going.

In the end, I think it all brings you back to old pets vs cattle debate. If
your server is manually provisioned, each process is carefully tuned, then
shell scripts are for you.

If you just want to say "install something_d" and have things work, across
thousands of systems, at the expense of uglier config and non-optimal file
layout -- then more advanced inits are way better.

------
Porthos9K
All I've got to say is that I'm glad the BSDs make decent workstations even
though desktop isn't their primary use case. Because I'm reading this and
thinking, "Oh, hell no."

I'm reacting like this because I honestly don't get it. Why does systemd need
a subsystem that touches /home?

~~~
theamk
It is all described in the first slides, I’d summarize it as “encrypted
decentralized roaming profile”.

It’s a pretty specialized feature - I’d myself would not want to use it. But I
can think of some situations where this can be very handy.

And from the practical standpoint, it is not that bad. As far as files access
goes, it is compatible with everything, and quering password db will also
work. The only thing that changed is how you create interactive users, and
it’s not like it was standardized before.

~~~
Porthos9K
I think I get it now. This is for _corporate_ desktop, not necessarily
personal use.

------
m45t3r
Reading the slides this seems really interesting. A way to allow you simple
copy your home (that may be in an encrypted loop file) to a Pendrive and have
all your configuration anywhere seems like a big win. This will make the only
stateful thing in my system (my home directory) much easier to backup and
move.

Also the death of /etc/shadow and /etc/passwd (state in a directory that
should only contain configuration files). And encrypted home on suspend.

Like most systemd things, this should be completely optional. Also like most
systemd things, people will complain that this is unnecessary bloat.

~~~
fhennig
It is completly optional, also it is optional to use home encryption (this
comes up a lot when people want to log in on a remote server with a user that
uses homed).

homed users and conventional users can exist side by side.

~~~
sverige
Funny, that's what I heard when systemd was introduced: "it's completely
optional." And yet today I don't think I would use both hands counting the
Linux distros _without_ systemd, though far more than that number tried and
finally gave up.

~~~
m45t3r
> though far more than that number tried and finally gave up.

I think people either should try to maintain their own distro, be a maintainer
for their distro of choice or stop complaining about the decisions maintainers
from their distro take for them.

I mean, at least in Arch systemd seemed to be the obvious choice: it reduced
the complexity for the maintainers. Arch used to be a combination of multiple
shells scripts maintained by Arch package maintainers. Since systemd they can
use the .service file that multiple programs already have upstream, or they
can write themselves one that is much easier and less error prone than the
shell script approach used before.

I am sure that the maintainers from Debian, Ubuntu, Fedora, OpenSUSE, Madriva,
etc. all analyzed the advantages/disadvantages of migrating to systemd vs.
maintaining their in-house solution (that they all had before, one way or
another). If you still discord from them, why are you using one specific
distro? You can pick any other one that is not using systemd, like Devuan,
Void Linux, Alpine, etc.

~~~
sverige
My point was that many who tried to avoid systemd found it to be very
difficult, despite the vague assurances up front that it would be "optional."
Now "the maintainers" (i.e., Lennart and friends) are contemplating making the
file system more opaque.

Instead of saying it will be optional, just say it up front: this is what Red
Hat wants, so it's coming to your distro soon too, whether you like it or not,
because it will become a dependency of systemd, or vice versa.

It's the lying about it that I can't stand.

~~~
theamk
> “the maintainers" (i.e., Lennart and friends)

Huh what? The Debian discussion was completely in the open, and I recommend
reading it, so you know why people choose systemd.

There was no Lennart’s influence, everyone was their own people. No one had
red hat agenda. All they wanted a better init system, it ended up being a
choice between systemd and upstart, and systemd won with a small margin. A
later GR vote across thousands of debian debs confirmed the decision.

Really, why do those theories gets repeated? We are not talking about
commercial companies and back room office politics, it is all in the open.

~~~
michaelmrose
If they opted for gnome it was going to be hard to avoid also picking systemd.

~~~
m45t3r
Hard, not impossible. Void Linux is using elogind: [https://github.com/void-
linux/void-packages/blob/master/srcp...](https://github.com/void-linux/void-
packages/blob/master/srcpkgs/gdm/template)

And BTW, if you don't like the way that Gnome is going you can fork it or use
another desktop. There are multiple desktops for Linux that are very polished
and doesn't depend on systemd.

------
mappu
There's a problem with loading the home directory as a loopback block device
from roaming USB disks - untrusted filesystems aren't safe to mount.

From [https://lwn.net/Articles/755593/](https://lwn.net/Articles/755593/)
"Unprivileged filesystem mounts, 2018 edition":

> There's little we can do to prevent people from exploiting flaws in the
> filesystem's on-disk format. No filesystem has robust, exhaustive
> verification of all it's metadata, nor is that something we can really check
> at runtime due to the complexity and overhead of runtime checking. [...] "Go
> run your filesystem in userspace with fuse if you want stronger security
> guarantees."

But the same topic is also discussed in many similar articles, e.g. more
recently regarding the likeliness of opening new bugs for everyone using
automount since the new EROFS filesystem has been merged into the mainline
kernel.

~~~
poettering
Yes this is a problem. To address this systemd-homed is careful to validate
the user record enclosed in the volume first (which includes checking its
signature against the keyring of accepted record signers) and checks whether
the provided user password can unlock it. Only after this validation and that
the fs actually matches the record we will mount it. Thus as long as the
employer trusts its employees enough things should be reasonably safe.

(To make this happen the user record is embedded into the LUKS2 header
metadata so that we can use it before mounting the fs)

~~~
Mrat
Hi, Lennart. My question isn't related to what you were answering in this
comment but it's related to some problems I have to deal since I'm constantly
moving my /home folder from a distribution to another.

I always have to delete files like ~/.local/share/applications/ _.desktop
because otherwise it will show stuff that shouldn 't be available in a
freshly-installed distribution and it makes me think it's _"contaminated"*. I
wanted to know how this new implementation deals with those cases.

BTW, congratulations! You made a systemd "hater" like me agree with you. I
would be really grateful if this solution made me forget about cleaning up my
home before a new install. Have a nice day!

------
CameronNemo
There was a recent /r/linux thread regarding
this.([https://reddit.com/comments/d6w03y](https://reddit.com/comments/d6w03y))
Lennart responds to some questions people had.

~~~
trynewideas
> User records are not frequently updated and are not typically updated by
> multiple players simultaneously.

Would love to see what Lennart measured and how he came to this conclusion.

~~~
wademealing
Is this difficult to believe, do you delete users hundreds of times a day ?

~~~
CameronNemo
Well he is 'reinventing' home directories as an independent concept. This
storage artifact could be updated frequently and over the network. The concern
may be insignifcant until this homed feature has its limits stretched.

~~~
theamk
That quote s about user record - full name, password, expirations, limits
etc.. how often do you change this?

It does not apply to user files, there is a completely different mechanism for
them

------
kylek
(Incoming downvotes. Sorry I can't contain myself. Yes, it's sarcasm and I
hate that I feel like I have to preface this)

>>>

    
    
      improve  
        intransitive verb
            To raise to a more desirable or more excellent quality or condition; make better.
        intransitive verb
            To increase the productivity or value of (land or property).
        intransitive verb
            To become better.

>>>

Either we need a new definition, or start calling it GNU/systemd

edit: What I'm actually trying to get at is- "are all distros that implement
systemd expected to jump on every major architectural change that Lennart&co
come up with?" Is this not asking a lot? That's a ton of weight and a lot
decisions that have been traditionally owned by the distros. Maybe nobody
actually wants to think about this stuff, though.

~~~
bitwize
> What I'm actually trying to get at is- "are all distros that implement
> systemd expected to jump on every major architectural change that Lennart&co
> come up with?"

Yes.

> Is this not asking a lot?

It isn't. Especially since Lennart & co. have done most of the hard work.

> That's a ton of weight and a lot decisions that have been traditionally
> owned by the distros.

That's kind of the point. The goal of systemd is to provide a single, unified,
comprehensive Linux platform and undo some of the fragmentation that has
occurred in the Linux space between distributions. For example, systemd
service files work the same irrespective of distro. Upstream developers need
supply only one service file that can then be used on all distros.

~~~
kylek
>> That's kind of the point. The goal of systemd is to provide a single,
unified, comprehensive Linux platform and undo some of the fragmentation that
has occurred in the Linux space between distributions.

Huh I guess I hadn't thought of it that way. I've always viewed the
"fragmentation" (opinionated differences giving the end-user more choice)
between distros as a feature, not a bug. I don't know, I still feel the
"systemd or not" choice still comes off a bit ham-handed. But maybe it doesn't
matter anymore (considering that all old/big distros that wanted to implement
it probably already have, and any new one is free to use it or not). Probably
also has to do with the barrier-to-entry of using Linux being far lower than
it used to be (maybe in part due to systemd?)

~~~
scrollaway
> _I 've always viewed the "fragmentation" (opinionated differences giving the
> end-user more choice) between distros as a feature, not a bug._

I see this opinion quite often and I think it's based far too much on "ancient
wisdom" and not actually grounded in reality.

Because in practice, the fragmentation has meant that people creating/selling
cross-platform desktop apps take one look at linux and think: "Yeah, this
isn't worth it".

It means a poorer user experience for Linux novices (and even advanced users),
because documentation doesn't always match what's on their desktop. They're
missing binaries. Arguments are different. Things are implemented differently
not even for the sake of being different, but simply because there was no
opportunity to reuse the work, so none was reused (and now backwards-
compatibility is in the way of changing that).

It also means that there's a ridiculous amount of duplicated work between all
the distributions. That duplicated work takes a toll on _all_ distributions,
which run on limited, usually-volunteer manpower.

Those distributions with less manpower, the ones that will actually try new
things rather than do something slightly-different, are the ones that are more
likely to die. The fragmentation between things that are essentially-the-same
creates a higher effort barrier to creating actual new things.

systemd is slowly fixing all of this, _and thank fuck_.

~~~
kylek
I smell what you're steppin' in. It (especially in combination with
flatpak/appimage/the-dockerization-of-everything) somewhat protects users from
poor decisions that might be made unwittingly by application developers (who,
rightfully, should be working on making the best application possible, rather
than digging into the brambles of "proper" packaging. For smaller projects
with a limited number of maintainers, anyways.)

That's all good and well I think. My biggest peeves will always be around its
logging and whatever systemd-resolved tries to do.

------
AstralStorm
So instead of writing a PAM module like normal people... Wait, it already
exists. pam_mount, used to typically mount ecryptfs.

Welcome to NIH.

~~~
poettering
Uh oh. This is implemented via a PAM module too. But it does substantially
more than pam_mount so not sure what you want. It's like claiming that UNIX
'find' is NIH because 'ls' already can show directory listings.

------
cosmonism
I'm confused. Why can't they remote login to a box with their home directory
encrypted?

Is it not enough to have the pubkey stored outside their home? e.g.

    
    
        # /etc/ssh/sshd_config
        AuthorizedKeysFile /var/ssh/%u/authorized_keys
    

Once they authenticate they can run cryptsetup or what-have-you. To me that
sounds way better than having randos guess your luks passphrase.

~~~
cnvogel
Yes, that's certainly a solution.

Or using a certification authority for users (TrustedUserCAKeys in
sshd_config), so that any user that has a signed certificate, and owns the
corresponding private key, would be allowed to login. No further updates of
authroized_keys files needed.

And, to further automate the ssh login, maybe your LUKS container could have a
second (Nth) key-slot being a random key RSA-encrypted with the other
machine's identity private key? ([https://bjornjohansen.no/encrypt-file-using-
ssh-key](https://bjornjohansen.no/encrypt-file-using-ssh-key) for examples)

But generally, I really dislike the use of LUKS in this case, as I think a
filesystem based encryption (not encrypting whole block devices) would make
more sense. I understand that this isn't as mature as LUKS, though.

------
lawnchair_larry
I think we need less dependence on systemd, not more. It’s already a mess.

~~~
scrollaway
I'd like to see you construct an actual reasonable argument that it's a mess,
that isn't based on hearsay or just "I liked it better the old way".

------
sifar
May be this is a naive question, but it talks about making home directories
portable. In that case how does it resolve when two different users on two
different machines with the same username try to move it to the same stick ?
How does it guarantee unique UIDs across different machines ?

------
drjesusphd
So this is how systemd takes over the Linux file system?

------
amos19870630
This actually looks like a really interesting idea, though I'm curious to see
how well it'd handle the combination of both local and shared storage.

------
waste_monk
Cancer now working to improve brain tissue handling.

