View previous topic :: View next topic |
Author |
Message |
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6156 Location: Dallas area
|
Posted: Sat Sep 21, 2019 9:50 am Post subject: systemd-homed ??? |
|
|
I peruse slashdot in the morning (have for years, yeah, I know, bad habit ) and ran across this
Quote: | Freshly Exhumed shares a report from Phoronix, detailing a new set of systemd capabilities shown off by lead developer Lennart Poettering at the annual All Systems Go conference:
Improving the Linux handling of user home directories is the next ambition for systemd. Among the goals are allowing more easily migratable home directories, ensuring all data for users is self-contained to the home directories, UID assignments being handled to the local system, unified user password and encryption key handling, better data encryption handling in general, and other modernization efforts. Among the items being explored by systemd-homed are JSON-based user records, encrypted LUKS home directories in loop-back files, and other next-gen features to offering secure yet portable home directories. Systemd-homed is currently being developed in Lennart's Git tree but hopes to see it merged for either systemd 244 (the current cycle) or systemd 245. |
coming soon to a distro near you _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54579 Location: 56N 3W
|
Posted: Sat Sep 21, 2019 10:22 am Post subject: |
|
|
Now ransomware only has to change your LUKS keys, not process every file. :)
There is no danger of any of this Anon-E-moose wrote: | coming soon to a distro near | me. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Sat Sep 21, 2019 10:35 am Post subject: Re: systemd-homed ??? |
|
|
Anon-E-moose wrote: |
Quote: | and other next-gen features to offering secure yet portable home directories. |
|
I can't wait an anal probe to login my user!!! |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6156 Location: Dallas area
|
Posted: Sat Sep 21, 2019 10:46 am Post subject: |
|
|
And the march towards being like windows continues ....
Neddy, yep, very bad idea
krinn, ssshhh, lets not give him any more ideas _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Sat Sep 21, 2019 12:46 pm Post subject: |
|
|
I saw this the other day and wanted to post here, but well a systemd+1 thread will be met with the same scorn, even tho the facepalm keeps coming.
I just don't know where to start... Their motives are to enable easy migration between OS's (I guess an image being loaded in different vm/ve and justWork(tm) )... however, that is already possible and the present problems are that which will plague this... different OS's will be at different versions of different userland software and might not even have it installed.
This just stinks of a registry that isn't a registry "but its JSON..." GNOME tried that using xml... _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
steve_v Guru
Joined: 20 Jun 2004 Posts: 411 Location: New Zealand
|
Posted: Sat Sep 21, 2019 12:50 pm Post subject: Re: systemd-homed ??? |
|
|
Quote: | modernization efforts. | Translation: Making shit more complicated for no discernable gain, making system configuration impossible for the average user without bloated GUI utilities, and ensuring everything is irrevocably tied to systemd.
Quote: | JSON-based user records | Jebus. WHY??? What is wrong with plaintext?
Quote: | coming soon to a distro near you | Not any distro I run or have anything to do with. LoL indeed.
I'm hoping this is actually some kind of joke, but it certainly fits the "nu-linux" over-integrated over-engineered pattern in a certain developers work... Gentoo is almost the last refuge from this insanity, please may it long remain so. _________________ Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3522
|
Posted: Sat Sep 21, 2019 2:28 pm Post subject: |
|
|
Is anyone else waiting for systemd to replace the entire /etc tree with "systemd.registry"? _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
steve_v Guru
Joined: 20 Jun 2004 Posts: 411 Location: New Zealand
|
Posted: Sat Sep 21, 2019 2:47 pm Post subject: |
|
|
depontius wrote: | Is anyone else waiting for systemd to replace the entire /etc tree with "systemd.registry"? |
Be careful what you wish for...
Frighteningly enough, I can absolutely see this happening. _________________ Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6156 Location: Dallas area
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22698
|
Posted: Sat Sep 21, 2019 3:59 pm Post subject: Re: systemd-homed ??? |
|
|
steve_v wrote: | Quote: | JSON-based user records | Jebus. WHY??? What is wrong with plaintext? | Plaintext is invariably not really plaintext, but some ad-hoc encoding that happened to cover the cases its original designers envisioned. Consider /etc/passwd. We don't put the password in it anymore, and we can't add any new fields to it because too many things know exactly what a record is supposed to look like and have their own private parser implementation. We can't put unusual values in the existing fields, because that too might confuse those parsers. For example, we can't give any field an embedded colon. Various magic values were carved out for the password field to tell readers whether the password was null, was in /etc/shadow, or is in NIS. Explicitly using an encoding that can represent any arbitrary character input, as JSON (among other formats) can do, is a defensible choice. It also makes it easier to write tools that dig in the data structure, because all the major languages already have parsers for JSON. Whether this particular "user record" data will be something that needs that flexibility and extensibility remains to be seen. |
|
Back to top |
|
|
steve_v Guru
Joined: 20 Jun 2004 Posts: 411 Location: New Zealand
|
Posted: Sat Sep 21, 2019 6:21 pm Post subject: Re: systemd-homed ??? |
|
|
Hu wrote: | Plaintext is invariably not really plaintext, but some ad-hoc encoding that happened to cover the cases its original designers envisioned. | Indeed, as are the majority of system configuration files on GNU/Linux. I don't have a problem with that.
Hu wrote: | Consider /etc/passwd. We don't put the password in it anymore, and we can't add any new fields to it because too many things know exactly what a record is supposed to look like and have their own private parser implementation. We can't put unusual values in the existing fields, because that too might confuse those parsers. | So the alternative is to rewrite all those things that know how to read /etc/passwd to include a JSON parser...
While this may be a good idea in principle, in reality I expect it will be a cat-herding exercise and result in an /etc directory with even more random file-encodings than we have now. At least the existing /etc/passwd is easy for a human to read, unlike JSON, XML, or any of the other suggestions that regularly rear their heads.
Hey, why don't we have two copies of /etc/passwd, one in JSON and one for compatibility with everything not developed by Lennart Poettering? How about /etc/shadow too? We could have the compatibility files dynamically updated by yet another crash-happy tentacle of systemd that subsumes /usr/bin/passwd... I foresee no pain at all from such a simple and elegant system.
Hu wrote: | Explicitly using an encoding that can represent any arbitrary character input, as JSON (among other formats) can do, is a defensible choice. | Had this choice been made on day-one, I'd agree. Now that we have an established software ecosystem built around text-streams and a bunch of sysadmins used to reading text files, I don't.
Which is more aggravating to pipe into awk/sed/grep/etc.? /etc/passwd as it is now, or a JSON file? Which is easier to read and modify in vi?
Sure, there are tools to make JSON human-readable in vi, but the files we have are already human-readable.
Hu wrote: | It also makes it easier to write tools that dig in the data structure, because all the major languages already have parsers for JSON. | True. I would still much prefer something that doesn't make my eyes bleed when I have to deal with it personally though.
Hu wrote: | Whether this particular "user record" data will be something that needs that flexibility and extensibility remains to be seen. | I'm going with "almost certainly not", as that's what I've found to be the case every time someone has tried this kind of stunt in the past. /etc/passwd for example - it's a simple file with a simple encoding, because it has a simple job to do and doesn't need anything more.
As with several other projects I might mention, this looks like a solution in search of a problem. It also looks like another crusade to make configuration easier for GUI tools to parse... GUI tools that I don't want and won't ever use.
That and it's systemd hoovering up yet more established functionality, escaping which is one of the reasons I'm using gentoo in the first place. _________________ Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6156 Location: Dallas area
|
Posted: Sat Sep 21, 2019 7:15 pm Post subject: |
|
|
I'm not sure how useful this (homed) will be in practice, at least for the larger userbase.
I think it was designed with 2 types of users in mind, those with laptops that also have a server/desktop login and container users, both cases seem to be more geared toward business use than home users.
It really doesn't need to be part of systemd, and other than being part of the systemd umbrella, I'm not sure how much of the systemd codebase it will share, well other than I'm sure it'll somehow use dbus as it's process communication. _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Sep 21, 2019 7:25 pm Post subject: |
|
|
A Slashdot post about a Phoronix post about a systemd autofs clone. Sounds about the most irrelevant and inconsequential thing imaginable. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54579 Location: 56N 3W
|
Posted: Sat Sep 21, 2019 7:26 pm Post subject: |
|
|
Anon-E-moose,
It will be like udev ... inseparable. Its a part of the One True Way. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3522
|
Posted: Sat Sep 21, 2019 9:13 pm Post subject: |
|
|
steve_v wrote: | depontius wrote: | Is anyone else waiting for systemd to replace the entire /etc tree with "systemd.registry"? |
Be careful what you wish for...
Frighteningly enough, I can absolutely see this happening. |
That wasn't a wish, unless it was a death-wish. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
389292 Guru
Joined: 26 Mar 2019 Posts: 504
|
Posted: Sun Sep 22, 2019 12:44 am Post subject: |
|
|
I'm genuinely surprised that so many things on the list are not part of systemd already, I thought they are. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6156 Location: Dallas area
|
Posted: Sun Sep 22, 2019 10:25 am Post subject: |
|
|
etnull wrote: | I'm genuinely surprised that so many things on the list are not part of systemd already, I thought they are. |
/home is the testbed ... next /etc then on to /usr/share, etc. Soon all your base are us _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Sun Sep 22, 2019 10:37 am Post subject: |
|
|
Anon-E-moose wrote: | etnull wrote: | I'm genuinely surprised that so many things on the list are not part of systemd already, I thought they are. |
/home is the testbed ... next /etc then on to /usr/share, etc. Soon all your base are us | there will be a systemd-ukerneld, which mounts a selected loopback to initiate the chosen sandboxes linux-kernel _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
tld Veteran
Joined: 09 Dec 2003 Posts: 1845
|
Posted: Sun Sep 22, 2019 3:14 pm Post subject: Re: systemd-homed ??? |
|
|
steve_v wrote: | Hu wrote: | It also makes it easier to write tools that dig in the data structure, because all the major languages already have parsers for JSON. | True. I would still much prefer something that doesn't make my eyes bleed when I have to deal with it personally though. | Agreed...not to mention that the vast majority of Linux config files are little more than effectively name/value pairs, or essentially variable assignments like Gentoo has in /etc/conf.d. Requiring a JSON parser for cases like that is just pure anti-KISS at best.
I actually just saw this thread today and it's the biggest face palm I've had in a while. No words at all.
Tom |
|
Back to top |
|
|
tld Veteran
Joined: 09 Dec 2003 Posts: 1845
|
Posted: Sun Sep 22, 2019 3:58 pm Post subject: |
|
|
Anon-E-moose wrote: | It really doesn't need to be part of systemd, and other than being part of the systemd umbrella, I'm not sure how much of the systemd codebase it will share, well other than I'm sure it'll somehow use dbus as it's process communication. | ...and better yet, I'll all but guarantee it'll somehow require "libsystemd" thus requiring everything else because, you know, "systemd isn't monolithic". I remember a great interview with one of the architects of BSD who mentioned a systemd feature that seemed useful, but when he dug into it, that was the case. His comment was "If your library name is lib<mydaemon> you're doing it wrong".
In another thread some time back, Fitzcarraldo (thanks!) posted this link, which I've finally started to read. For those who haven't it's really interesting, and somewhat terrifying frankly:
https://blog.darknedgy.net/technology/2015/10/11/0/
Tom |
|
Back to top |
|
|
tholin Apprentice
Joined: 04 Oct 2008 Posts: 205
|
Posted: Sun Sep 22, 2019 6:04 pm Post subject: |
|
|
The video of the talk is up at https://streaming.media.ccc.de/asg2019/relive/164
One of the ideas of the new reinvented home directories is to give each user a LUKS encrypted loopback file like /home/foobar.home that is unlocked when the user logs in and gets mounted as /home/foobar. That will break a whole bunch of stuff that depends on user directories existing even when the user is logged out but let's ignore that.
One of the the main motivations for having encrypted loopback files is "the decryption key needs to be removed from memory so that I know for sure that if someone steals my laptop [...] they should not be capable of getting any access to my harddisk". "This is something people might not find important but I think it's one of the most important things in this entire approach".
So before suspending a laptop luksSuspend will be run on the encrypted home. I considered using that approach when I setup disk encryption on my laptop but I concluded that it's infeasible to do that securely. LuksSuspend will only wipe the encryption key used for accessing the disk. It will not remove any of the already decrypted data in pagecache. Maybe there isn't anything sensitive in pagecache, or maybe there is. Just suspending and hoping for the best is not a good idea.
To suspend securely with encrypted disks the pagecache of the disk must be wiped (overwritten). All programs with read permission to the encrypted fs must be killed and their memory wiped. All free ram must be wiped in case some program held sensitive data and then quit. That is still not enough. If the unlock passwords was read from an usb keyboard the usb subsystem might have old buffers where the key presses could still be stored. All kernel subsystems which could be used to handle key material must be wiped.
The threat model he mention is "I if go though customs to a country that I don't trust" but there is no way this approach is secure against that. You simply don't know what sensitive data remains in ram. Don't he realize that? Or if he is realizing it why is he claiming this is secure?
During the Q&A (46:00) someone points out the problem and Lennart responds that perhaps sensitive data could be forced out to encrypted swap (hint: no, not security). Just use hibernation instead of suspending to be sure nothing is left in ram. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3522
|
Posted: Sun Sep 22, 2019 11:35 pm Post subject: |
|
|
OK, so for various reasons I kept the Windows installation on my laptop, though I almost always boot Linux. In fact, most of what I do on Windows is Windows Update, which I did today. I think it was five reboots worth, or at least I rebooted it five times - and that was from the last update in late Spring / early Summer. one of the steps said that my laptop might reboot multiple times, but I didn't hang around to watch it.
And this relates to this thread how???
Because I imagine L.P. saying, "I didn't really get this inode stuff, and didn't really like it anyway. So I've written systemd-fs for our next-generation filesystem with xxx advanced features." But inodes wouldn't be one of them. Welcome Linux to multiple-reboot software updates. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Sep 23, 2019 4:49 am Post subject: |
|
|
Actually the idea of a "home-on-a-stick" (maybe ro) that doesn't break stuff and is automatically handled is not bad .....
Just to mention etcd is now in redhat hands _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
steve_v Guru
Joined: 20 Jun 2004 Posts: 411 Location: New Zealand
|
Posted: Mon Sep 23, 2019 5:40 am Post subject: |
|
|
erm67 wrote: | Actually the idea of a "home-on-a-stick" (maybe ro) that doesn't break stuff and is automatically handled is not bad ..... | I'm pretty certain I could implement that without systemd or JSON user data if I could be bothered... _________________ Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Sep 23, 2019 6:54 am Post subject: |
|
|
The world is full of people that could do stuff but doesn't because they don't bother, most of them are just delusional losers.
pics or it didn't happen _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
|