Systemd-Homed: Systemd Now Working to Improve Home Directory Handling(phoronix.com)
phoronix.com
Systemd-Homed: Systemd Now Working to Improve Home Directory Handling
https://www.phoronix.com/scan.php?page=news_item&px=systemd-homed
97 comments
“Logged in”? Does this seriously not accommodate cronjobs? Well, this isn't the first time they have ignored non-interactive and distributed uses, and it always seems like they're targeting a game console rather than a real computer.
He is talking about homedir encryption with auto-lock, and this fundamentally incompatible with cronjobs.
Sorry, you got to choose - cronjobs or secures encryption. No one can have both.
Sorry, you got to choose - cronjobs or secures encryption. No one can have both.
“Will the user hit ^D in time?” is some kind of movie-inspired imitation of security. If I can't trust that computer while I'm not logged in, I shouldn't trust it any more when I am. Encryption keys should be opaquely held by processes as capability tokens.
I'm sorry this is wrong. Full disk encryption combined with locking said encryption on suspend secures a machine from trivial invasions of privacy while not in use or theft of the machine. Cron implementations and individual jobs can intelligently figure out how to handle missed jobs while the machine was off or suspended. Example doing the missed job once at some interval after resuming, doing it per runtime interval instead of per calendar interval, just doing the next scheduled interval.
Systemd has its own cron type implementation called timers and I'm sure it logically would work user jobs in at times the user is logged in, in the same way cron works around the fact that the user is sometimes suspended or off for indeterminate time frames.
In most cases it wont even have to. Most users machines have a lifecycle like this
POST 15 seconds Optional FDE passphrase entry 10 seconds Starting up 30 seconds to 2 minutes User login 10 seconds Operation some duration for hours to weeks Shutdown
The encrypted and or logged out state are transitory states on the way to the machines single owner entering credentials to access the device and the machine is only in those states 0.001% of its lifecycle.
For people worried about substantial secrets as opposed to a thief stealing their personal data it may be wise to segregate THAT data on a separate encrypted volume that is only unlocked during use so that opening up your machine to watch cat videos on Youtube doesn't expose thousands of patient records or company secrets.
Cron is only incompatible with homedir encryption if your scheme relies on time sensitive things which effect things OFF your computer happening ON your machine which is powered on frequently enough but not logged in as you sufficiently to complete the tasks it must also require data on your home dir to complete.
I say it has to be factors that effect off computer items because otherwise the task can simply be done as soon as you log in.
I say it must require data on your home dir to complete else your system can be told to do it for you.
For the small number of cases where one might imagine a shared computer might be turned on enough but logged in as other users one can imagine ignoring homedir encyption and simply using FDE with multiple passphrases for individual users. This will necessarily be less secure as all users would be constrained by permissions by able to break into other users local data. At this point we have identified the use case that is actually incompatible.
Shared computers with privileged local data with mutually untrustworthy users on which users need to regularly run tasks which require access to user data regardless of who is logged in.
The logical solution to which is a server, segregation to be provided by different virtual machines if needed.
Systemd has its own cron type implementation called timers and I'm sure it logically would work user jobs in at times the user is logged in, in the same way cron works around the fact that the user is sometimes suspended or off for indeterminate time frames.
In most cases it wont even have to. Most users machines have a lifecycle like this
POST 15 seconds Optional FDE passphrase entry 10 seconds Starting up 30 seconds to 2 minutes User login 10 seconds Operation some duration for hours to weeks Shutdown
The encrypted and or logged out state are transitory states on the way to the machines single owner entering credentials to access the device and the machine is only in those states 0.001% of its lifecycle.
For people worried about substantial secrets as opposed to a thief stealing their personal data it may be wise to segregate THAT data on a separate encrypted volume that is only unlocked during use so that opening up your machine to watch cat videos on Youtube doesn't expose thousands of patient records or company secrets.
Cron is only incompatible with homedir encryption if your scheme relies on time sensitive things which effect things OFF your computer happening ON your machine which is powered on frequently enough but not logged in as you sufficiently to complete the tasks it must also require data on your home dir to complete.
I say it has to be factors that effect off computer items because otherwise the task can simply be done as soon as you log in.
I say it must require data on your home dir to complete else your system can be told to do it for you.
For the small number of cases where one might imagine a shared computer might be turned on enough but logged in as other users one can imagine ignoring homedir encyption and simply using FDE with multiple passphrases for individual users. This will necessarily be less secure as all users would be constrained by permissions by able to break into other users local data. At this point we have identified the use case that is actually incompatible.
Shared computers with privileged local data with mutually untrustworthy users on which users need to regularly run tasks which require access to user data regardless of who is logged in.
The logical solution to which is a server, segregation to be provided by different virtual machines if needed.
Not entirely true, a cronjob at user level can just ask for the password.
Not sure how that work? The computer just stands there, with no one around, and “please enter password for user joe” appears? Or same thing happens on a shared computer while another user is logged in - what next?
I mean, sure one can code this, but I cannot imagine many situations where it will be useful. I think if you want cronjobs, you just have to use service users.
I mean, sure one can code this, but I cannot imagine many situations where it will be useful. I think if you want cronjobs, you just have to use service users.
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.
It's a good guess. The first sentence of Lennart answer to this question is :
> Well. Homed is intended primarily for client machines, i.e. laptops and thus machines you typically ssh from a lot more than ssh to if you follow what i mean.
andrerm left it out of his quote. He also left this part out. It's about openssh and pam :
> Maybe they solve this eventually but lets see. In the meantime you at least get a friendly msg explaining the situation briefly and what to do.
> Well. Homed is intended primarily for client machines, i.e. laptops and thus machines you typically ssh from a lot more than ssh to if you follow what i mean.
andrerm left it out of his quote. He also left this part out. It's about openssh and pam :
> Maybe they solve this eventually but lets see. In the meantime you at least get a friendly msg explaining the situation briefly and what to do.
Huh? I ssh into my laptops all the time...
I think the confusion here might be a lack of clear distinction in the discussion between "ssh password auth" and "ssh pub key auth".
My impression is that the result of some of the design decisions might make "ssh pub key auth" work less often. IOW: one would need to login via password auth before pub key auth would work.
The alternate ("somehow have pubkey auth work and then ask for a crypto password") sounds like it would need some work and it isn't clear how useful it would be: if I'm already needing to enter a password anyhow, why bother with the previous pubkey auth?
As discussed elsewhere, it's plausible that some mechanism could be developed to use the ssh key material (or some other stored key material) to have the unlocking happen without manual password entry, but that would require some additional development.
Really, all this boils down to is that "login mechanisms aren't quite flexible enough", and the presentation touches on this to some extent as well.
My impression is that the result of some of the design decisions might make "ssh pub key auth" work less often. IOW: one would need to login via password auth before pub key auth would work.
The alternate ("somehow have pubkey auth work and then ask for a crypto password") sounds like it would need some work and it isn't clear how useful it would be: if I'm already needing to enter a password anyhow, why bother with the previous pubkey auth?
As discussed elsewhere, it's plausible that some mechanism could be developed to use the ssh key material (or some other stored key material) to have the unlocking happen without manual password entry, but that would require some additional development.
Really, all this boils down to is that "login mechanisms aren't quite flexible enough", and the presentation touches on this to some extent as well.
I read that you would have to physically log into your machine in order to mount home but ssh login including via public key auth would work thereafter.
Public key ssh login at a machine you hadn't sat down and logged in would fail in the same fashion as one would expect if the home partition was absent.
This would seem to be passable in many cases right up until you have to reboot the machine for some reason and its no longer possible to login.
There is good reason to prefer a public key vs password. Pubkey auth means you aren't entering anything over the wire that can be intercepted and nobody can guess or use your password if they knew it to access your local system.
For example someone who shoulder surfed your password couldn't gain the ability to log into your machine from across town.
If they shoulder surfed your passphrase/password and then stole your physical machine they would of course have everything they needed in a typical configuration even with encryption. You could of course go further and require a keyfile AND a passphrase and hope it is harder to say steal a small usb device on your keychain and your computer than just your computer.
At this point it really looks like you are defending against a targeted attack on your data rather than simple theft.
Public key ssh login at a machine you hadn't sat down and logged in would fail in the same fashion as one would expect if the home partition was absent.
This would seem to be passable in many cases right up until you have to reboot the machine for some reason and its no longer possible to login.
There is good reason to prefer a public key vs password. Pubkey auth means you aren't entering anything over the wire that can be intercepted and nobody can guess or use your password if they knew it to access your local system.
For example someone who shoulder surfed your password couldn't gain the ability to log into your machine from across town.
If they shoulder surfed your passphrase/password and then stole your physical machine they would of course have everything they needed in a typical configuration even with encryption. You could of course go further and require a keyfile AND a passphrase and hope it is harder to say steal a small usb device on your keychain and your computer than just your computer.
At this point it really looks like you are defending against a targeted attack on your data rather than simple theft.
Wouldn't it similarly have issues with the various desktop UI logins? Or do these all use systemd-logind?
The quoted paragraph says it uses a PAM module to unlock it, and PAM is independent of systemd.
The ones that don't use systemd-logind can be safely ignored because they aren't modern, or compatible with the modern Linux ecosystem.
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.
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.
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.
I can agree, since we switched to systemd, a lot of work is simply no longer necessary and the reliability due to new features where increased. Overall a big win against the old init system.
Don't hate new stuff, it's OK to have same changes and sorry to say, the old home directory is awful. Maybe the new will bring something good as well (don't know yet, but I try to stay open minded). For example I would love to see roaming home profiles in Linux, not only for the desktop but for servers as well.
Don't hate new stuff, it's OK to have same changes and sorry to say, the old home directory is awful. Maybe the new will bring something good as well (don't know yet, but I try to stay open minded). For example I would love to see roaming home profiles in Linux, not only for the desktop but for servers as well.
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....
this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1....
this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
OpenRC is similarly concise. The runit run scripts used on Void Linux are too, but they rarely take into account complicated dependencies so they are fragile.
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)
(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)
> 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:
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.
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
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.
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.
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.
logging is covered here:
https://netbsd.gw.com/cgi-bin/man-cgi?rc+8+NetBSD-current https://netbsd.gw.com/cgi-bin/man-cgi?rc.subr+8+NetBSD-curre...
and dependency ordering here:
https://netbsd.gw.com/cgi-bin/man-cgi?rcorder+8+NetBSD-curre...
design rationale & further discussion here:
https://netbsd.gw.com/cgi-bin/man-cgi?rc+8+NetBSD-current https://netbsd.gw.com/cgi-bin/man-cgi?rc.subr+8+NetBSD-curre...
and dependency ordering here:
https://netbsd.gw.com/cgi-bin/man-cgi?rcorder+8+NetBSD-curre...
design rationale & further discussion here:
Luke Mewburn, "The Design and Implementation of the NetBSD rc.d system",
Proceedings of the FREENIX Track: 2001 USENIX Annual Technical
Conference, USENIX Association,
http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/full_papers/mewburn/mewburn.pdf,
June 25-30, 2001.I can see the rc runner itself will save output to /var/run/rc.log . This is great, as far as shell-based systems go -- of course not as good as systemd/upstart (which separate by service), but better than many linux's init systems.
Next, I wanted to check if "run_rc_command" suppressed the stdout/stderr of the program it was running. And here is where I hit a first difficulty:
- The rc.subr manpage you referred to does not seem to mention logging it in any way.
- So I looked in the source.. and it is 1300 line shell script [1], with run_rc_command being pretty complex function, with thousands of lines of code.
I found answer to my question (apparently it does not care about stdout/stderr at all), but this was non-trivial.
Compare it to systemd, which just have this information in the official manpages [2].
Are you still claiming shell-based init scripts are simpler?
(Expert level question: you have a third-party Java app, which provides a single sh file for you to run. Can you use it with your "10 line init script"? Why not?)
[1] https://github.com/IIJ-NetBSD/netbsd-src/blob/e4505e0610ceb1...
[2] https://www.freedesktop.org/software/systemd/man/systemd.exe...
Next, I wanted to check if "run_rc_command" suppressed the stdout/stderr of the program it was running. And here is where I hit a first difficulty:
- The rc.subr manpage you referred to does not seem to mention logging it in any way.
- So I looked in the source.. and it is 1300 line shell script [1], with run_rc_command being pretty complex function, with thousands of lines of code.
I found answer to my question (apparently it does not care about stdout/stderr at all), but this was non-trivial.
Compare it to systemd, which just have this information in the official manpages [2].
Are you still claiming shell-based init scripts are simpler?
(Expert level question: you have a third-party Java app, which provides a single sh file for you to run. Can you use it with your "10 line init script"? Why not?)
[1] https://github.com/IIJ-NetBSD/netbsd-src/blob/e4505e0610ceb1...
[2] https://www.freedesktop.org/software/systemd/man/systemd.exe...
> Systemd has always been hyper focused on the desktop/laptop experience
No, most features of systemd are focused in Servers (systemd-resolved itself is one example, it can be used by Desktops, however the reason for its creation was containers that needed to have faster DNS resolution).
Actually, systemd-homed is the first systemd feature that I know that the reason to exist is for Laptop users (and Desktop users somewhat less). Most new features of systemd are created for either servers or embedded users. For example:
- Portable services (user case: servers): http://0pointer.net/blog/walkthrough-for-portable-services.h...
- IP Accounting (user case: servers): http://0pointer.net/blog/category/projects.html
- Dynamic users (user case: servers): http://0pointer.net/blog/dynamic-users-with-systemd.html
- SD-event (user case: all): http://0pointer.net/blog/introducing-sd-event.html
- SD-bus (user case: all): http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
- Stateless systems (user case: embedded): http://0pointer.net/blog/revisiting-how-we-put-together-linu...
For all of those features, only SD-bus is more relevant to Desktop user case since it is where DBus is more common. However Dbus is also used in server/embedded user cases sometimes. The rest of features may be interesting for Desktop however they mostly are used for either servers or embedded systems.
> it will be forced upon server setups
I am really curious of which systemd features are being forced in any distro. systemd-resolved for example is not used by default in any distro that I know (Debian, Ubuntu, Arch, NixOS).
No, most features of systemd are focused in Servers (systemd-resolved itself is one example, it can be used by Desktops, however the reason for its creation was containers that needed to have faster DNS resolution).
Actually, systemd-homed is the first systemd feature that I know that the reason to exist is for Laptop users (and Desktop users somewhat less). Most new features of systemd are created for either servers or embedded users. For example:
- Portable services (user case: servers): http://0pointer.net/blog/walkthrough-for-portable-services.h...
- IP Accounting (user case: servers): http://0pointer.net/blog/category/projects.html
- Dynamic users (user case: servers): http://0pointer.net/blog/dynamic-users-with-systemd.html
- SD-event (user case: all): http://0pointer.net/blog/introducing-sd-event.html
- SD-bus (user case: all): http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
- Stateless systems (user case: embedded): http://0pointer.net/blog/revisiting-how-we-put-together-linu...
For all of those features, only SD-bus is more relevant to Desktop user case since it is where DBus is more common. However Dbus is also used in server/embedded user cases sometimes. The rest of features may be interesting for Desktop however they mostly are used for either servers or embedded systems.
> it will be forced upon server setups
I am really curious of which systemd features are being forced in any distro. systemd-resolved for example is not used by default in any distro that I know (Debian, Ubuntu, Arch, NixOS).
I'm pretty sure Ubuntu 18.04 uses systemd-resolved by default, not that it matters all that much to me.
even Fedora doesn't use systemd-resolvd, so NOTHING was forced
Debian added it ‘behind people’s backs’ in buster / Debian 10 when you updated from the previous stable. On one laptop I have I was still running systemd and it took me quite a while to figure out why my dns resolution broke (I block port 53 outbound at my router and it was trying to use 8.8.8.8 despite my resolv.conf saying something else).
It’s not just that they added their own caching resolver - it’s that it then ignores the decades old standard resolv.conf and hijacks system name resolution by default.
That finally prompted me to remove systemd from the one machine I had it on.
It’s not just that they added their own caching resolver - it’s that it then ignores the decades old standard resolv.conf and hijacks system name resolution by default.
That finally prompted me to remove systemd from the one machine I had it on.
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?
I'm reacting like this because I honestly don't get it. Why does systemd need a subsystem that touches /home?
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.
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.
I think I get it now. This is for corporate desktop, not necessarily personal use.
> Why does systemd need a subsystem that touches /home?
because they haven't written one that touches home yet?
because they haven't written one that touches home yet?
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.
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.
This sounds interesting enough to implement in a systemd-free way.
I do not think it would be notably magical. Please contact via https://cameronnemo.gitlab.io if you do take up the effort.
It's pretty easy to backup and move your home or any other directory now. If anything this actually makes such more complicated.
Incidentally you can already lose luks keys on suspend and reacquire them on resume now. Its called go-luks-suspend
https://github.com/guns/go-luks-suspend
It works as long as suspend does.
Incidentally you can already lose luks keys on suspend and reacquire them on resume now. Its called go-luks-suspend
https://github.com/guns/go-luks-suspend
It works as long as suspend does.
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.
homed users and conventional users can exist side by side.
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.
> 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.
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.
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.
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.
> “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.
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.
If they opted for gnome it was going to be hard to avoid also picking systemd.
Hard, not impossible. Void Linux is using elogind: https://github.com/void-linux/void-packages/blob/master/srcp...
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.
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.
> My point was that many who tried to avoid systemd found it to be very difficult
Avoiding systemd is not difficult, it is just that using systemd makes things easier. You have one codebase shared between multiple distros where most of your init logic is, instead of having to maintain your own init scripts somewhere by yourself.
> because it will become a dependency of systemd, or vice versa.
This is not true. I don't know many things that are dependend of systemd running as a init system.
Avoiding systemd is not difficult, it is just that using systemd makes things easier. You have one codebase shared between multiple distros where most of your init logic is, instead of having to maintain your own init scripts somewhere by yourself.
> because it will become a dependency of systemd, or vice versa.
This is not true. I don't know many things that are dependend of systemd running as a init system.
> Avoiding systemd is not difficult
Well, for sysadmins who are in charge of hundreds of systems in datacenters and are accustomed to upgrading regularly, it's really not that easy.
Well, for sysadmins who are in charge of hundreds of systems in datacenters and are accustomed to upgrading regularly, it's really not that easy.
Is the complaint that systemd is so useful that nearly every distro includes it?
The distributors have no choice. They have to bend over backwards if they want to be inclusive. Gentoo has their own Udev fork for that; Devuan folks realized it's easier to fork a whole distro.
Basically at some point you had a choice: you either ship Systemd or can't ship Gnome because of GDM's dependency on Systemd. At this point we knew we're royally screwed up. It's almost funny that in Debian you can replace any element of the system, even the Linux kernel with a BSD one, but you can't replace the init system, even though several alternatives exist. Our problem with Systemd is the lack of choice.
Basically at some point you had a choice: you either ship Systemd or can't ship Gnome because of GDM's dependency on Systemd. At this point we knew we're royally screwed up. It's almost funny that in Debian you can replace any element of the system, even the Linux kernel with a BSD one, but you can't replace the init system, even though several alternatives exist. Our problem with Systemd is the lack of choice.
> or can't ship Gnome because of GDM's dependency on Systemd
Void Linux is using GDM with elogind and seems fine: https://github.com/void-linux/void-packages/blob/master/srcp...
> even the Linux kernel with a BSD one
You know, Debian GNU/kFreeBSD is as most a fork of Debian as Devuan. They share most of the packages definitions, however some core parts (like the init scripts) are _very_ different.
> but you can't replace the init system, even though several alternatives exist
Well, you can. It is just that Debian maintainers don't want to maintain this complexity in their own system. Supporting only one init system is already difficult, imagine supporting N init systems like you're suggesting (and this includes bug reports: do you really think that this is a good usage of the time from maintainers to support that niche init system with 3 users?).
However there is nothing impeding you to use your own Debian installation with any init system you want. Or even better: switch to Devuan.
Void Linux is using GDM with elogind and seems fine: https://github.com/void-linux/void-packages/blob/master/srcp...
> even the Linux kernel with a BSD one
You know, Debian GNU/kFreeBSD is as most a fork of Debian as Devuan. They share most of the packages definitions, however some core parts (like the init scripts) are _very_ different.
> but you can't replace the init system, even though several alternatives exist
Well, you can. It is just that Debian maintainers don't want to maintain this complexity in their own system. Supporting only one init system is already difficult, imagine supporting N init systems like you're suggesting (and this includes bug reports: do you really think that this is a good usage of the time from maintainers to support that niche init system with 3 users?).
However there is nothing impeding you to use your own Debian installation with any init system you want. Or even better: switch to Devuan.
> It is just that Debian maintainers don't want to maintain this complexity in their own system
Sigh... don't believe the FUD, there's a standing Debian Technical Committee decision [1] that multiple init systems must be supported, it's just that the Devuan people don't want to work on a distro that includes a systemd source package in its archive, so instead of maintaining the sysvinit scripts in the Debian archive they went off forking.
[1] https://lists.debian.org/debian-devel-announce/2014/08/msg00...
Sigh... don't believe the FUD, there's a standing Debian Technical Committee decision [1] that multiple init systems must be supported, it's just that the Devuan people don't want to work on a distro that includes a systemd source package in its archive, so instead of maintaining the sysvinit scripts in the Debian archive they went off forking.
[1] https://lists.debian.org/debian-devel-announce/2014/08/msg00...
TIL. So it is even easier and I don't know what's the problem with dvfjsdhgfv. I think unless Debian stopped adopting systemd nobody would be happy.
Where did anyone say that using systemd would be optional on distros built on systemd? It's the init system, if the distro provides an alternative it's "optional", if the distro doesn't it isn't.
Sounds like your beef is with a specific distro, not systemd in general.
Sounds like your beef is with a specific distro, not systemd in general.
I'm sure they all gave up because of politics, too, and not because systemd gets way more right than it gets wrong despite a vocal minority of noncontributory angst.
Unfortunately, it will probably take ten years to see the real effects of these decisions on the ecosystem. I hope you're right that this is the way to go, but I fear I'll be right that Linux will be at least as opaque as Windows to anyone who wants an entry point into learning about operating systems and systems administration without having to pay to take classes.
I much prefer my system with systemd, because it's less opaque than when i started using Linux in 1998 (attempted earlier, but failed).
I hope what you say is true and will remain true in a year or five. Because I was happy about Systemd at the beginning (it looks like we have another init, good). Then it turned out it wasn't engineered to be an independent init system and it practically killed any possibility of replacing it with another init should the user want it. The distributors capitulated one by one. The last big one, Debian, didn't give up without a fight and produced Devuan. But because it's not an official Debian variant, if your living depends on it, you will hesitate before you use it for long-term projects. That's the sad consequence of a few design decisions plus a bit of politics.
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/ "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.
From 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.
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)
(To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs)
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!
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!
(Incoming downvotes. Sorry I can't contain myself. Yes, it's sarcasm and I hate that I feel like I have to preface this)
>>>
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.
>>>
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.
> 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.
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.
>> 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?)
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?)
> 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.
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.
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.
That's all good and well I think. My biggest peeves will always be around its logging and whatever systemd-resolved tries to do.
I think it really depends on what "fragmentatation" is. I think people think different libcs, compilers, DEs are mostly good.
I definitely think it is ridiculous though, that I couldn't use something seemingly fundamental like an init script across distros.
I definitely think it is ridiculous though, that I couldn't use something seemingly fundamental like an init script across distros.
That's sort of what I meant by the barrier-to-entry comment. Maybe a decade ago one might say: an init script is simple, "anyone" (read: anyone using linux 10 years ago) should be able to throw one together to get something to start. That "anyone" has likely already put in a certain amount of effort to learn some of the grittier parts of the system they're using. Ain't nobody got time for details like that anymore :)
[deleted]
There was a recent /r/linux thread regarding this.(https://reddit.com/comments/d6w03y) Lennart responds to some questions people had.
> 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.
Would love to see what Lennart measured and how he came to this conclusion.
Well. How frequently do you update your user record in /etc/passwd? I mean, if you do this a million times per second then maybe your are doig something wrong, no? I update my user record maybe every year when I update my password, but if you do that once per ms then uh oh
Given that the whole system is targeted for laptops, this seems somewhat obvious and does not seem to be something you need to measure?
The worst thing I can think of is classroom environment - and even that would be at most 1 update per hour, which is pretty infrequent in the context (the update frequency needs to be much bigger than the clock skew, which is normally under a second)
And even that assumes that each record is updated every time user logs in (since each record is stored separately). In practice, records could be added or removed to the system, but the actual modification will be pretty rare - once initial setup is done, it will be only periodic password changes.
The worst thing I can think of is classroom environment - and even that would be at most 1 update per hour, which is pretty infrequent in the context (the update frequency needs to be much bigger than the clock skew, which is normally under a second)
And even that assumes that each record is updated every time user logs in (since each record is stored separately). In practice, records could be added or removed to the system, but the actual modification will be pretty rare - once initial setup is done, it will be only periodic password changes.
In cases where they are, you're probably using a central account management system like ldap anyway.
Is this difficult to believe, do you delete users hundreds of times a day ?
I don't on my personal laptop, but my workplace's wacky automation does on my work laptop, and school and library automation definitely does on shared workstations, including laptops.
I get that that's the problem of the automation, not the daemon, but I'm curious about who exactly is representing users when the people running a project state things like that so unequivocally, and if those users are just excluded from any benefits from a system like this because fuck 'em.
I get that that's the problem of the automation, not the daemon, but I'm curious about who exactly is representing users when the people running a project state things like that so unequivocally, and if those users are just excluded from any benefits from a system like this because fuck 'em.
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.
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
It does not apply to user files, there is a completely different mechanism for them
So instead of writing a PAM module like normal people... Wait, it already exists. pam_mount, used to typically mount ecryptfs.
Welcome to NIH.
Welcome to NIH.
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.
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.
Is it not enough to have the pubkey stored outside their home? e.g.
# /etc/ssh/sshd_config
AuthorizedKeysFile /var/ssh/%u/authorized_keys
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 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.
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 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.
We actually use something like the above. But thats not sufficient since we cannot set up the PAM session fully if $HOME is not accessible because we can't acquire a password for it...
[deleted]
[deleted]
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 ?
So this is how systemd takes over the Linux file system?
[deleted]
[deleted]
[deleted]
I think we need less dependence on systemd, not more. It’s already a mess.
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".
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.
Cancer now working to improve brain tissue handling.
> 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?