You are not logged in.

#1 2024-11-14 07:29:28

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Systemd unit on first user login when using homectl encrypted home

So question in the subject. Tried several things but nothing worked for me. Tried things included: creating a unit that watch for a folder update, creating a unit that depends on a <username>.home unit, creating a user unit and probably something else I have already forgot.

My main usecase for that is I need to perform some actions that requires home directory of the main user be decrypted. As an example, a little bit adhoc but still should not be this hard, to automount external encrypted device on user login by using script that contains plain stored password. (In such case user login would be like a master password)

Do somebody tried to have have user units with homectl or any other methods to start things on login?

Offline

#2 2024-11-14 12:29:22

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Systemd unit on first user login when using homectl encrypted home

I'm not using homectl, but does this mean all the systemd-user.unit examples don't work when using homectl? I don't ad hoc see a manual reference, so I wonder if that can be a case.

Offline

#3 2024-11-14 15:00:12

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

It is probably because they are tried to be loaded after the login itself but not after a decryption and mounting. But still should try some simple example to see whether it loads it or not

The simple unit I created:
[Unit]
Description=Hello
[Service]
ExecStart=/usr/bin/logger "Hello, World!"
[Install]
WantedBy=default.target


Enabling it via systemctl --user enable --now hello-world.service (prints hello world)


After reboot and login the service "could not be found", so I guess systemd does not find unit at all

PS. Still, if someone knows any other ways to achieve the same functionality then please do tell me. I am now thinking to create some system script that will start on system startup and would monitor by polling user folder to see if the content changes and then do what I need to do. But that feels kind of wrong to make such a polling

PS2. Or is there a way achieve something like this using PAM?

Last edited by matryoshka (2024-11-14 15:16:45)

Offline

#4 2024-11-15 19:41:16

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Systemd unit on first user login when using homectl encrypted home

You can use PAM modules to do a custom luks unlock of a home directory/partition, but mixing with systemd-homed is asking for trouble. Becuase it's supposed to host a self-contained home. Perhaps, rather have your secrets encrypted inside the home dir e.g. with file encryption, or perhaps use a mount helper (cryptmount, zulucrypt - I've not used them), and autostarting via your WM/DE.

Though, user units should work somehow with homectl as well, of course. Perhaps someone else can figure that.

Offline

#5 2024-11-15 23:17:14

mithrial
Member
Registered: 2017-03-05
Posts: 151

Re: Systemd unit on first user login when using homectl encrypted home

I don't think this is ever being supported. The goal of homed is to have an encrypted container that is only open, when the user provides their password. Starting a service is only possible afterwards.
Automatically unlocking defeats the purpose of having it encrypted in the first place.

Offline

#6 2024-11-16 01:14:41

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

mithrial wrote:

I don't think this is ever being supported. The goal of homed is to have an encrypted container that is only open, when the user provides their password. Starting a service is only possible afterwards.
Automatically unlocking defeats the purpose of having it encrypted in the first place.

If that's an answer for my post then no, I did not mention I need auto unlocking. I literally in a need to figure out how to start a service after decryption.

Strike0 wrote:

Though, user units should work somehow with homectl as well, of course. Perhaps someone else can figure that

Yeah, it was strange to not find any mention of that. It's like something wrong with my setup so it mentioned nowhere.
As about using separated dir for secrets: it is just having all managed by homectl is much easier and that my first time using it. Also, no gui is used with this pc (al least natively) as it mostly accessed remotely

Offline

#7 2024-11-16 10:14:58

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Systemd unit on first user login when using homectl encrypted home

If it was much easier, you'd not be posting and ask questions touching all sorts of broad topics to work around homectl instead of output relating to it.

The service will simply fail, because the path is not available when systemd dependencies first touch it (being enabled). You can simply leave the unit disabled and start it manually after you login remotely. It's literally one command.
What's the output of

systemctl get-default
systemctl --user status hello-world.service

after boot.

Offline

#8 2024-11-16 10:32:23

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

Strike0 wrote:

What's the output of

systemctl get-default
systemctl --user status hello-world.service

after boot.

$ systemctl get-default
graphical.target 
$ systemctl --user status hello-world.service
Unit hello-world.service could not be found. 

Offline

#9 2024-11-16 18:33:27

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Systemd unit on first user login when using homectl encrypted home

So, graphical.target does seem ideal, if you log in via remote cli usually. But foremost the status indicates your test did not work, and we still don't know where you saved the unit you enabled. I think you should repeat it and post the status again after it started.

Offline

#10 2024-11-16 19:33:06

snakeroot
Member
Registered: 2012-10-06
Posts: 176

Re: Systemd unit on first user login when using homectl encrypted home

Have you considered exploring the following:
--having the unit be a per-user unit in /home/matryoshka/.config/systemd/user/ ? This should only run once matryoshka' s home directory is mounted
--having a .path unit triggered by DirectoryNotEmpty=yes and monitoring /home/matryoshka.

Offline

#11 2024-11-17 02:00:07

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

Strike0 wrote:

So, graphical.target does seem ideal, if you log in via remote cli usually. But foremost the status indicates your test did not work, and we still don't know where you saved the unit you enabled. I think you should repeat it and post the status again after it started.

The test was to confirm my assumption about systemd are trying to find units in a user folder before it gets mounted and so this is why it could not be found. I described it earlier:

me wrote:

Enabling it via systemctl --user enable --now hello-world.service (prints hello world)

After reboot and login the service "could not be found", so I guess systemd does not find unit at all

This is outoput after it was enabled and executed:

$ systemctl --user enable --now hello-world.service
$ systemctl --user status hello-world.service
○ hello-world.service - Helloo
     Loaded: loaded (/home/decky/.config/systemd/user/hello-world.service; enabled; preset: enabled)
     Active: inactive (dead) since Sun 2024-11-17 10:24:40 JST; 3s ago
   Duration: 36ms
 Invocation: 0e4630a1ef414978af3099629ae6b46b
    Process: 821 ExecStart=/usr/bin/logger Hello, World! (code=exited, status=0/SUCCESS)
   Main PID: 821 (code=exited, status=0/SUCCESS)
   Mem peak: 1.4M
        CPU: 5ms

Nov 17 10:24:40 arch-vostro systemd[345]: Started Helloo.
Nov 17 10:24:40 arch-vostro decky[821]: Hello, World!

---

snakeroot wrote:

--having the unit be a per-user unit in /home/matryoshka/.config/systemd/user/ ? This should only run once matryoshka' s home directory is mounted

Output above. Unfortunately it tries to do that before decryption and mounting, by my understanding.

snakeroot wrote:

--having a .path unit triggered by DirectoryNotEmpty=yes and monitoring /home/matryoshka.

 
I probably would need a help with the unit content as I am not sure I am doing it right:

Unit:

 [Unit]
 Description=Trigger when /home/decky is not empty
 ConditionPathExists=/home/decky
 ConditionDirectoryNotEmpty=/home/decky

 [Service]
 Type=oneshot
 ExecStart=/usr/bin/logger -t directory-not-empty "yay"

 [Install]
 WantedBy=multi-user.target 

After reboot and loggin in:

 
$ systemctl status decky-not-empty.service
○ decky-not-empty.service - Trigger when /home/decky is not empty
     Loaded: loaded (/etc/systemd/system/decky-not-empty.service; enabled; preset: disabled)
     Active: inactive (dead)
  Condition: start condition unmet at Sun 2024-11-17 10:34:39 JST; 1min 33s ago
             └─ ConditionDirectoryNotEmpty=/home/decky was not met

Nov 17 10:34:39 arch-vostro systemd[1]: Trigger when /home/decky is not empty was skipped because of an unmet condition>
$ pwd
/home/decky

That was as .service and now as a .path. Content:

 [Unit]
 Description=Watch /home/decky for non-emptiness

 [Path]
 DirectoryNotEmpty=/home/decky
 Unit=decky-not-empty.service

 [Install]
 WantedBy=multi-user.target

decky-not-empty.service for a .path unit:

[Unit]
Description=Trigger when /home/decky is not empty

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t directory-not-empty "yay"

[Install]
WantedBy=multi-user.target

After reboot it is loaded but fail to trigger as home gets mounted (probably the reason):

$ systemctl status decky-not-empty.path
● decky-not-empty.path - Watch /home/decky for non-emptiness
     Loaded: loaded (/etc/systemd/system/decky-not-empty.path; enabled; preset: disabled)
     Active: active (waiting) since Sun 2024-11-17 10:55:42 JST; 1min 25s ago
 Invocation: fa119aeacde3403f87969f617b7893a7
   Triggers: ● decky-not-empty.service

Nov 17 10:55:42 arch-vostro systemd[1]: Started Watch /home/decky for non-emptiness.

Offline

#12 2024-11-17 14:35:32

mithrial
Member
Registered: 2017-03-05
Posts: 151

Re: Systemd unit on first user login when using homectl encrypted home

If it's a user service, it should be in the user folder, not /etc.

Do you have a log to support your statement that this does not work? (In .config and enabled)

Did you activate lingering for this user?

Last edited by mithrial (2024-11-17 14:35:57)

Offline

#13 2024-11-17 14:42:04

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

mithrial wrote:

If it's a user service, it should be in the user folder, not /etc.

Do you have a log to support your statement that this does not work? (In .config and enabled)

Did you activate lingering for this user?


Not sure I am following but see my prev post where I showed that user units are not loaded at all after reboot.

Yes, lingering is enabled:

loginctl list-users
  UID USER  LINGER STATE
60126 decky yes    active

Offline

#14 2024-11-17 16:04:32

mithrial
Member
Registered: 2017-03-05
Posts: 151

Re: Systemd unit on first user login when using homectl encrypted home

You did not show a log of the user service being enabled and the according error message. Above, you show the error message for the system service.
However, I think linger is the culprit:
https://github.com/systemd/systemd/issues/34151

Last edited by mithrial (2024-11-17 16:08:36)

Offline

#15 2024-11-18 00:50:00

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

mithrial wrote:

You did not show a log of the user service being enabled and the according error message. Above, you show the error message for the system service.

Here was my test with hello-world service:

me wrote:

   

me wrote:

Enabling it via systemctl --user enable --now hello-world.service (prints hello world)

    After reboot and login the service "could not be found", so I guess systemd does not find unit at all

$ systemctl --user status hello-world.service
Unit hello-world.service could not be found. 

This is outoput after it was enabled and executed:

$ systemctl --user enable --now hello-world.service
$ systemctl --user status hello-world.service
○ hello-world.service - Helloo
     Loaded: loaded (/home/decky/.config/systemd/user/hello-world.service; enabled; preset: enabled)
     Active: inactive (dead) since Sun 2024-11-17 10:24:40 JST; 3s ago
   Duration: 36ms
 Invocation: 0e4630a1ef414978af3099629ae6b46b
    Process: 821 ExecStart=/usr/bin/logger Hello, World! (code=exited, status=0/SUCCESS)
   Main PID: 821 (code=exited, status=0/SUCCESS)
   Mem peak: 1.4M
        CPU: 5ms

Nov 17 10:24:40 arch-vostro systemd[345]: Started Helloo.
Nov 17 10:24:40 arch-vostro decky[821]: Hello, World!

Offline

#16 2024-11-18 01:13:08

matryoshka
Member
Registered: 2022-05-14
Posts: 32

Re: Systemd unit on first user login when using homectl encrypted home

mithrial wrote:

However, I think linger is the culprit:

You are right. Enabling hello-world.service again and disabling lingering leads to the user service being executed.

The lingering was enabled as quick solution to homed locking user's home folder when there is no user session but I was having some docker containers running that was using files from decrypted user home.
So now need to figure out how to find a replacement for a lingering or write a user unit that would enable lingering after login lol.

Offline

#17 2024-11-18 11:52:04

mithrial
Member
Registered: 2017-03-05
Posts: 151

Re: Systemd unit on first user login when using homectl encrypted home

Thanks for the confirmation.

I agree with the GitHub topic that this would defeat the whole process of having systemd-homed in the first place: unlocking user home only if they are present.
The idea of it was to have a roaming solution: have your home on a USB drive and use any PC with the same home.
This would not work with linger or your use-case because the encrypted home container might not be available during boot.

Offline

Board footer

Powered by FluxBB