As for homed, time will tell how it gets implemented. However, even if networkd isn't widely adopted. Doesn't resolvd solve so many problems present in linux? I kid.

anyway. On an encrypted system I can suspend to ram in xfce session. Return to normal operation with no hitches. Probably not the same as dismounting though! Although from a root terminal I'm sure you could remount it, but maybe would have to reboot and close a bunch of processes running from non-root user! I'm sure someone smart could write a script to dismount a home partition and remount the thing and get xorg back up and running without leaking the passphrase. Manually mounting from terminal isn't hard just takes time

https://github.com/tuxlovesyou/sshfs-home
is homed something like this? I stumbled on this browsing github. I usually don't install much from git if ever.

Thing is about convenience is you are trading something.

So far the only systemd feature I like is nspawn. It seems powerful.

farmatito wrote:

where is it stored by systemd-homed?

In the LUKS2 header, the entire volume being un-mounted for the suspend operation.

Technical details here: https://systemd.io/HOME_DIRECTORY/

Isn't it a little risky to encrypt the whole file system as a loop mountable file.
Couldn't one bad block in the LUKS header or maybe even in the file body make the file undecryptable?

What's the emoji for broken by design?

[
Can you do that with sysvinit?

What's the emoji for broken by design?

ToxicExMachina wrote:

Don't call those features optional.

But they are optional. For example, can you name a single distribution that's actually using systemd-networkd?

Networkd? What about logind and udev?

That's the great example of SystemD flawness. So called "consistency" of SystemD is just overcomplication. Sandboxing is not the feature accessible only via SystemD.

I have no this problem at all. If I don't want such security flaw I just won't use suspend. Security isn't about making illusion of secure state.

where is it stored by systemd-homed?

In the LUKS2 header, the entire volume being un-mounted for the suspend operation.

Technical details here: https://systemd.io/HOME_DIRECTORY/

So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?

Just out of curiosity where is it stored by systemd-homed?

Don't call those features optional.

But they are optional. For example, can you name a single distribution that's actually using systemd-networkd?

I would agree that most features can be implemented with other tools but I like the consistency of the systemd tool set and also the fact that they're all being produced and maintained by the same team, just as you would find in real UNIX systems.

But there are some features that are unique to systemd. I've already mentioned masking units, another is hardening of services:

https://www.ctrl.blog/entry/systemd-ser … ening.html

Check this out:

empty@E485:~ $ systemd-analyze security --no-p
UNIT                                 EXPOSURE PREDICATE HAPPY
accounts-daemon.service                   9.5 UNSAFE    ?    
alsa-state.service                        9.5 UNSAFE    ?    
anacron.service                           9.5 UNSAFE    ?    
auditd.service                            9.5 UNSAFE    ?    
btrfs-scrub@-.service                     9.5 UNSAFE    ?    
colord.service                            8.7 EXPOSED   ?    
cron.service                              9.5 UNSAFE    ?    
dbus.service                              9.5 UNSAFE    ?    
emergency.service                         9.5 UNSAFE    ?    
gdm.service                               9.7 UNSAFE    ?    
getty@tty1.service                        9.5 UNSAFE    ?    
hddtemp.service                           9.5 UNSAFE    ?    
iwd.service                               5.7 MEDIUM    ?    
polkit.service                            9.5 UNSAFE    ?    
rc-local.service                          9.5 UNSAFE    ?    
rescue.service                            9.5 UNSAFE    ?    
rtkit-daemon.service                      6.9 MEDIUM    ?    
sysfsutils.service                        9.5 UNSAFE    ?    
systemd-ask-password-console.service      9.3 UNSAFE    ?    
systemd-ask-password-wall.service         9.3 UNSAFE    ?    
systemd-fsckd.service                     9.5 UNSAFE    ?    
systemd-initctl.service                   9.3 UNSAFE    ?    
systemd-journald.service                  4.3 OK        ?    
systemd-logind.service                    4.1 OK        ?    
systemd-networkd.service                  2.8 OK        ?    
systemd-resolved.service                  2.1 OK        ?    
systemd-rfkill.service                    9.3 UNSAFE    ?    
systemd-timesyncd.service                 2.0 OK        ?    
systemd-udevd.service                     8.3 EXPOSED   ?    
upower.service                            7.2 MEDIUM    ?    
user@1000.service                         9.1 UNSAFE    ?    
uuidd.service                             9.1 UNSAFE    ?    
empty@E485:~ $

Can you do that with sysvinit?

So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?

I asked the same question over at the MX forums and one of their developers claimed that the "solution" was not to use suspend. And I think they were being serious

Head_on_a_Stick wrote:

steelpillow wrote:

Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release

You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.

[1] Like most of systemd's tools.

Don't call those features optional. They are pure EEE. SystemD is not GNU/Linux - it's svchost.exe. Home directories in svchost.exe-like service is the greatest insanity achieved recently.

More like launchd by apple.

Just for the record, I'm not an advocate. I find the enormous code base and memory usage of systemd objectionable. But I do like some of the features. For me systemd is a bit like cheesecake: I like the taste but I know it's bad for me

All of useful features from SystemD can be implemented with a standard tool set accessible in GNU/Linux OS. Moreover: they were implemented many times before SystemD was developed. If nobody made features like "portable home directories" then such features are obvious and already exist or they aren't demanded.

steelpillow wrote:

Looks like it's full steam ahead for homed "portable home directories", now merged in ready for the next release

You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.

[1] Like most of systemd's tools.

Don't call those features optional. They are pure EEE. SystemD is not GNU/Linux - it's svchost.exe. Home directories in svchost.exe-like service is the greatest insanity achieved recently.

let me introduce HOAS, if you read their signature all will be made clear to you.  They have a history/track record on other fora as well of similar "behavior".

That does not surprise me. Still, anybody who has a Life glider for an avatar and suffers anomie at the foibles of the human condition is all right by me.

Head_on_a_Stick wrote:

steelpillow wrote:

why come and troll a community created expressly to expunge it all from our lives?

I'm bored.

I have to admit, that is the most convincing argument I ever heard from a systemd advocate.

steel, let me introduce HOAS, if you read their signature all will be made clear to you.  They have a history/track record on other fora as well of similar "behavior".

steelpillow wrote:

why come and troll a community created expressly to expunge it all from our lives?

I'm bored.

I have to admit, that is the most convincing argument I ever heard from a systemd advocate.