
Systemd Home Directories - signa11
https://systemd.io/HOME_DIRECTORY/
======
j0057
The merge request for this feature is here:
[https://github.com/systemd/systemd/commit/4119d1e60a111bacca...](https://github.com/systemd/systemd/commit/4119d1e60a111bacca359b61b5bc3dae29932b67)
\-- more than 21K new lines of code.

I'm not too worried about this being a "predictable interface names" type of
solution to a problem I'm not having. What I'm really worried about is that of
those 21K lines of code, only about 100 lines deal with testing, in the form
of two bash scripts performing end-to-end tests against the main executable
`homectl`.

At $DAYJOB, we find that to achieve any sort of acceptable coverage (which
we've arbitrarily defined as 80% or better) -- you'd expect the ratio of
production code to unit test code to be close to 1:1, and not anywhere near
the 200:1 like this code here.

I mean, either those are some _very_ efficient E2E tests, or we have a small
number of happy paths being covered here, and we the users will have to weed
out all the corner cases that weren't tested.

Moreover, since these are E2E tests and not unit tests, that makes me
immediately worry about the quality of the code. I know that unit testing is
not very common on C-land, but is it really that unheard of in C-land in 2020?

~~~
ilovecaching
In the kernel with have selftests, which are basically just regular binaries
run by make. I didn't do a lot of C unit testing before I started writing
selftests, but now I don't see a reason not to, I just made my own little
version of the selftest makefile and use that. C code can be tested like any
other code it's just made more difficult by the fact that most C code is very
concrete and doing systemy things that are harder to isolate.

------
kbumsik
I don't understand why they are using JSON, especially systemd already use an
INI-like config format extensively.

Maybe because they are not web devs so that they haven't had an annoying
moment when they realize there is no proper way to add comments in
package.json?

~~~
fctorial

        {
            ...
            "comment": "this is a comment",
            ...
        }

~~~
jolmg
Or you know, you can just do your language equivalent of:

    
    
      grep -Pv '^\s*#'
    

to remove comments, passing the output of that to the JSON parser. The
extension could be modified to .cjson, .json.commented, or something.

Good thing JSON doesn't permit literal newlines in strings. Any valid JSON
should be able to go through that comment filter without getting modified.

~~~
catalogia
That's nice and all, but you'll still have trouble reinserting those comments
when writing JSON. And if you don't have that, you have a config file which
can only be read, not written. And if you accept that, then what was the point
of using JSON in the first place?

~~~
jolmg
> you'll still have trouble reinserting those comments when writing JSON.

Sure. I wouldn't even try.

> And if you don't have that, you have a config file which can only be read,
> not written.

Just like most config files.

> And if you accept that, then what was the point of using JSON in the first
> place?

To not define your own format and be able to use ready-made parsers.

It's not like I'm advocating for the use of JSON over other choices like YAML.
I'm just replying to a comment about how to add comments to a JSON with a
better alternative. If someone wants to use JSON over other choices for
whatever reason and the only thing holding them back is the lack of comments,
then this is a valid way to add comments, I believe.

If you use a string property, you can't split your comment among multiple
lines. You could perhaps do an array of strings or something, but I think
adding a simple commenting syntax like this is neater.

EDIT: Fixed double negative in penultimate paragraph.

------
stubish
The article is describing a solution, but can anyone describe the problem or
an article discussing it? I'm having trouble coming up with use cases where
this is the best solution.

~~~
emmelaich
This article seems pretty snarky but OK.

[https://hackaday.com/2019/10/16/pack-your-bags-systemd-is-
ta...](https://hackaday.com/2019/10/16/pack-your-bags-systemd-is-taking-you-
to-a-new-home/)

~~~
jackewiehose
I still don't get it. The goal is to have your $HOME-directory on an usb-stick
and use it on different computers?

That would require having the same software versions installed on every
system. But even then it wouldn't work because the user-settings stored in
$HOME might depend on the hardware, e.g. monitor setup etc.

~~~
hottycat3
I think this is not for private users but for companies where the same or
similar software and hardware configuration is used across systems.

~~~
catalogia
Usually in configurations like that, the org likes having the ability to scan
user home directories at will, for a variety of reasons. In my experience in
those kind of networks, home directories are often on a centralized NFS/CIFS
server.

------
dreamcompiler
I already have a Swiss army knife program that manages my life, makes
sandwiches, and takes my dog to the groomer. It's called Emacs. I don't need
another.

~~~
zeveb
And Emacs uses a nice, simple, sane, universal configuration file format
(S-expressions) while systemd uses .ini files (on Unix!), JSON, binary and no
doubt something else somewhere else.

Hmmm, maybe it'd be worthwhile to just make emacs PID 1.

~~~
throwaway17_17
I think the use of .ini files is exceptionally appropriate for systemd. The
developers are at there most transparent here, it is essentially them saying
“we want to be Windows, we want to be the ones who control your system, we
make the decisions and you should be thankful that insightful, expert, never
ever ever wrong developers like us grace you with this software.” (Obvious
fake quote, is obvious) I know the sarcasm is heavy there, but the attitude of
the developers of systemd seems to be honestly geared in this direction. So,
Of course they use .ini files on Unix, because they want the same sort of mono
monster, one true path OS that Windows has.

~~~
CameronNemo
Fwiw systemd definitely does not use ini files. It uses some weird scripting
language that looks sort of like ini but has logical operators, clear
statements, and the ability to assign multiple values to one key.

------
hiisukun
One of the things I am hoping for with this change is an easy way for me to
log on to any computer I have 'synchronised' (such as my home laptop, desktop,
or perhaps the wife's laptop if it has network access to home) and have the
same home operating environment.

Will it work? Will the small tradeoffs be worth it? (Like remotely logging in
via ssh to a locked desktop machine somewhere...) ...

I guess I'm thinking the Chromebook style experience, but without the google
involvement.

Separately - I've often wondered if iPhones couldn't be a bit more user
agnostic in this way, perhaps among a family. Couldn't a son pick up his
mother's iphone, log on with is Apple ID from the lock screen (assuming she
has enabled 'family share') and have access to his messages, accounts,
contacts, etc, but not large media? I can't see Android getting there sooner,
but this would be a very useful feature I think.

~~~
viraptor
> I can't see Android getting there sooner

Why? iPhones still don't support multiple users natively as far as I can tell.
Android has this by default since... 7? 8?

Once you have everything set to sync to google services, it's really close to
having this behaviour.

~~~
jasonvorhe
Multi user support came with Android Lollipop in 2014.

------
jasonjayr
This is new to me, and I watched through the video, and in usual fashion, any
use case that he and his group thinks are not common, are just hand-waved away
"that's not common" "You shouldn't do it that way" "If you want to use this,
don't do that".

Yet, all the things he mentioned, like, remotely accessing a locked laptop via
ssh, or maintaining a external user database for a cluster of machines in
LDAP, are things I do on a regular basis.

He also mentioned something about requiring a privileged daemon to change your
ssh keys? Is there any more information about that?

Given the gravity of systemd, and all it's ancillary services, how long till
this is the one true way? How does this work in the case of true remotely
accessible multi-user systems?

~~~
neurobashing
my (possibly dumb) personal "conspiracy theory": some time in the relatively
recent future there is going to be The Grand Linux Userspace Fork. There's
going to be "SystemD with the Linux Kernel" (the SystemD system with Gnu
utilities and the Linux kernel if you're into that sort of thing) and then
"classic Linux", which is just "not using SystemD".

We already sorta have this now. What I'm (half-jokingly) suggesting is a big
ugly fork a la Emacs/XEmacs, where the world visibly and somewhat incompatibly
separates.

And like that fork we'll end up with everything more-or-less reconciling
eventually, but it's going a weird ride until then.

~~~
anonymou2
there is devuan already

------
smabie
If I could just switch to OpenBSD for all my work I would be really happy,
Linux and all the junk on it is a dumpster fire. Now that we’re in the late
stage of Linux being built out of a huge pile of seperately developed
components the usability of the system has plummeted to an absurd level. I
thought the config file story was bad, and now systemd wants to add auto
generated json to the mix (in a top level file of my home directory, no less).

Now Linux feels like all the other “enterprise” systems I deal with on a daily
basis: baroque, complex, confusing, and over-engineered.

~~~
ColanR
I moved to void for similar reasons. Eventually I'll move to openbsd, but void
is a nice stepping stone.

------
philips
The homectl command has some nice utilities too:

with USER COMMAND: This command is useful for running privileged backup
scripts and such, but requires authentication with the user's credentials in
order to be able to unlock the user's home directory.

resize USER BYTES: Change the disk space assigned to the specified home
directory.

[https://www.freedesktop.org/software/systemd/man/homectl.htm...](https://www.freedesktop.org/software/systemd/man/homectl.html#)

Also, if this makes setting up an encrypted home directory even slightly
easier I am all for it. I setup ecryptfs on Rasbian a few weeks ago and there
are a few steps that feel hacky if using a headless host and ssh.

~~~
CameronNemo
I'm pretty sure homed does not support (purely) headless use cases.

See minute 20:00: [https://media.ccc.de/v/ASG2019-164-reinventing-home-
director...](https://media.ccc.de/v/ASG2019-164-reinventing-home-
directories#t=1184)

~~~
philips
that is a bummer

------
Tecuane
> Inside of the home directory a file ~/.identity contains the JSON formatted
> user record of the user. It follows the format defined in JSON User Records.

Why couldn't this have gone into ~/.config/? There's enough garbage cluttering
my home directory.

~~~
userbinator
Also this:

 _Since the user record is cryptographically signed the user cannot make
modifications to the file on their own (at least not without corrupting it, or
knowing the private key used for signing the record)._

That sounds like something that shouldn't even be in the user's own home
directory.

...and JSON, of all things. Every aspect of systemd which I've worked with
seems to be full of sprawling complexity and overengineering, and this is no
exception. I know "it's not the UNIX philosophy" is a common dismissive
complait about it, but looking at the design gives a very different feeling
than the "original UNIX" designs, which felt humble and simple.

~~~
clktmr
>...and JSON, of all things.

Right? Reasoning was "the web people are using it too". Why not just use key
value based config files like every other system tool?

~~~
stubish
Likely because, despite looking similar, those key/value and .ini style config
files like every other system tool are actually hundreds of subtly
incompatible or poorly specified formats. Unicode handling, whitespace
handling, quoting, indentation, multi-line, line continuation, comments, non-
string datatypes, lists, maps... you use YAML for human maintained and YAML or
JSON for machine so people can use an off the shelf parser instead of
implementing your particular key/value specification. Even TOML is better than
rolling your own, since at least it has a common specification.

------
dusted
I'm not sold on having plaintext-files which cannot be edited by hand. I'm
only slightly doubtful that this will do us great in the future, but I think
I'll be a late adopter. I imagine there is a lot of unforeseen consequences.

There's also the deal with recovery from bad situations (tm) or reviving long-
dead home accounts.

------
inamberclad
I wonder if there's any other decent way to implement these features. Is
systemd the inevitable solution to complex issues like this, or is there a
more unixy way to achieve all this?

Edit: isn't JSON technically not free-as-in-freedom?

~~~
CameronNemo
>Edit: isn't JSON technically not free-as-in-freedom?

One implementation was nonfree due to that whole don't be evil clause. Systemd
uses json-c, which is permissively licensed from what I remember.

------
bpfrh
I thought one of the big selling points for this was the ability to move the
homedirectory from one device to another via usb or hdd?

Then how will they verifiy the signature of the user json file?

So I can't simply remount the user profile on another system?

Seems like a step back.

~~~
Aardwolf
> I thought one of the big selling points for this was the ability to move the
> homedirectory from one device to another via usb or hdd?

I've been able to do this for decades, just copy the files. Why would I want
systemd for that?

systemd has already made my textual log files binary and only accessible with
their own viewer. Now it's going to apply its philosophy to my home directory
too?

~~~
Spivak
You have a pendrive containing your encrypted home directory and you can plug
this drive in to a machine that _doesn 't a priori have your user account
info_ and log in to your account without administrative privilege.

This could genuinely be a viable lightweight alternative to LDAP/IPA in
offices that hotdesk. Just sign the user's drive once and they can plug-in to
any workstation.

~~~
qu4z-2
I don't really understand why they bother to encrypt it if you're going to be
typing your password into presenter laptops, etc...

~~~
Spivak
Because someone who steals your drive can’t decrypt it? How could you possibly
design a system where you can plug a drive into an openly hostile machine,
decrypt and use it, and have that machine not be able to access your password
or files?

------
zzo38computer
Maybe this is useful to some people, but I think that it is not useful to me
and that what I currently have is good. (I don't need the XDG stuff either
though, and I don't use it.)

------
e12e
What happens if you have a user called "lennart.homedir"?

~~~
guerrilla
Either it's lennart.homedir.homedir or you've found a bug.

~~~
e12e
So, you've got two users, "lennart" and "lennart.homedir"...

I guess it would only be a problem when migrating, systemd is presumably happy
to have lennart's home dir in lennart.homedir, and lennart.homedir's homedir
in lennart.homedir.homedir...

Ed: actually km more concerned with how this (doesn't) work with Pam, getent
etc. If ldap, yellow pages or /etc/paaswd specify a home-dir that's not at
/home/<username>... Should the system still look at <whatever path>.homedir?
But only for interactive logins? Will a daemon running as the user have a
different home dir? Will cron? At? The system processing dot.foward/sieve
filters?

------
znpy
But what if somebody already has data on some other volume-managing filesystem
(like, say, ZFS) ?

------
jchw
This seems pretty cool. A lot of the eCryptFS based home directory encryption
stuff felt difficult to manage and not very sturdy whereas the fscrpyt and
LUKS options here seem like they will be solid.

Q: am I understanding correctly that you cannot use btrfs subvolumes while
also using fscrypt? does it not make sense to use both?

CIFS home directories is another feature I’m excited for. I’m sure it would
have plenty of downsides to using a local filesystem but as of right now I
find it cumbersome to have non-local home directories at all.

------
stubish
How is the key handling being done? If the .identity file is signed, then
workstations will need to look up the key on some keyserver to see if the key
has been revoked. This also limits use to online-only.

Without key revokation and online-only, ex-employees plugging in their home
directories and regaining their employee privileges, because the trusted
.identity file says they are in the staff group.

------
z3t4
What about ZFS?

------
anonsivalley652
Some celebrity software developers just seem to love making arbitrary, costly
churn changes to existing standards, APIs and conventions to either feed their
egos or hype themselves while imposing pointless costs, changes and risks on
untold millions or billions of systems and users. Consumerist fashionabilism
and obsolescence breaking changes rarely, if ever, serve a legitimate purpose.
SMH.

~~~
nickik
Jesus dude. Maybe once in the your life consider that not everybody likes the
same thing as you. People like you are the reason this is a toxic community.

------
__jal
I think this may be where I step off the train. I grumbled, but can live with
it as init, and it is easy enough to disable the ntp and name resolution
nonsense to use decent tools.

Buy systemd has no business sticking its nose in authentication or storage, or
more generally telling me how to manage users. This is a no.

~~~
anderskaseorg
If you want to rage at systemd, you can do that equally well with or without
this optional feature: nothing changes unless you specifically tell systemd-
homed to manage your home directory.

~~~
__jal
Why does any criticism of systemd have to be due to "rage"? There is this
ongoing behavior whereby anything other than fawning praise is treated as
irrational and emotion-driven.

You may as well ask why Lennart rages so hard against ZFS.

~~~
anderskaseorg
I’m not saying that all systemd criticism is irrational. I’m saying that this
systemd criticism is irrational.

~~~
modo_mario
So this will be disabled by default? It will not become a default and as such
nothing will start to depend on it as a default?

Also remarks and doubts on the use of json for this purpose is completely
irrational?

~~~
cycloptic
Systemd is just an upstream project. It's up to your distro to ship it to you
and then it's up to you if you want to use some feature or you want to do it a
different way. This feature doesn't even do anything unless you create the
user with "homectl".

If another open source program depends on it by default, then you can patch it
to remove the dependency. If you disagree with the concept of JSON, feel free
to write your own data format.

I have zero interest in using this feature, but still I find it really
embarrassing that I have to regularly explain this basic concept of open
source here. And I don't mean that as a dig at you, I mean it in the sense
that there is a lot more work we have to do.

~~~
modo_mario
I decided to not act on it, take it easy and roll with defaults. After all
alternatives remained, it is an upstream project indeed, etc But I took quite
a bit of interest in the discussion as it raged on over the years those
arguments you've used I've seen time and time again.

Especially this: "If another open source program depends on it by default,
then you can patch it to remove the dependency." and "then it's up to you if
you want to use some feature or you want to do it a different way."

Now recently also Debian has decided to drop support for other init systems.
It just wasn't practical anymore. Now you get to be on the lookout when you
"want to use some feature or you want to do it a different way." because if
you don't you end up with shit like this:
[https://news.ycombinator.com/item?id=19291067](https://news.ycombinator.com/item?id=19291067)
Now we get to see hilarious stuff like a systemd developer asking tmux to add
systemd specific code to work around systemd's own default behaviour. Now we
get BSD's putting in work to deal with the prevalence of Systemd. Now we get
those working with embedded linux putting in work to deal with the prevalence
and dependency on SystemD. Because at the end of the day the systemd devs
don't care about ulibc, non linux and what have you whilst at the same time
seeming to really want to set the standard for as much as possible.

