bug#33260: Invocation of per-user shepherd - design needed

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic <address@hidden> ezt írta (időpont: 2018.
nov. 5., H, 2:04):
>
> Hi,
>
> this is a known problem in GuixSD (not in shepherd) and I don't think anyone 
> fixed
> it yet, because it requires some design (and is kinda harder than ignoring the
> problem and letting the user choose - see below).
>
> There is only rudimentary support for distinguishing sessions from users in 
> GuixSD
> (I guess nowadays everyone is using a computer of their own and people don't
> remember huge shared computers which you would dial into multiple times from
> different sites (not necessarily after hanging up the previous connection) -
> I work with the latter daily so I do remember).
>
> Shepherd assumes to be run per user (for non-root), not per session.
> For the vast majority of tasks-to-be-automated, that is what you want.
>
> But who starts the per-user shepherd?
>
> Right now, nobody.
>
> I manually edited my session startup file (in my case ~/.fluxbox/startup) to
> invoke "shepherd" and expect it to error on subsequent sessions except for the
> first one for this user - so only one shepherd per user will actually stay 
> running.
>
> This is a simple way to do it and I prefer it to any more complicated 
> solutions -
> since it's in the unix spirit of "worse is better" (in this case: 
> non-sarcastic).
>
> (For a more universal (non-fluxbox, it's too old) way, use ~/.config/autostart
> and put a "shepherd.desktop" file there)
>
> This assumes that nobody will clean up session processes when the session 
> ends,
> otherwise it will do the wrong thing (i.e. kill the per-user shepherd even 
> though
> other sessions of that user still need it).
>
> The assumption is justified because of the following:
>
> The right design overall for the system would be to clean up USER processes
> when all sessions of that user ended (this is not the default for elogind, but
> it could be enabled by the logind.conf option "KillUserProcesses").  (This
> would break Screen if not started right away with the session, though)
> In any case, the "simple way" above works when KillUserProcesses=no and
> also when KillUserProcesses=yes, so for me problem solved ;P
>
> (Also, traditionally UNIX would kill the controlling (that is, first) process
> that was started in a terminal once that terminal is disconnected (kill via
> sending that controlling process SIGHUP).
> I don't think that that is a problem here since that controlling process is
> usually the shell, not shepherd).
>
> There are multiple other ways to handle starting the per-user shepherd, but
> they are kinda complicated and all require new GuixSD services:
>
> * One way would be to monitor /run/user (see elogind for why), wait until a 
> new
> subdirectory appears, and then launch the per-user shepherd (as that user,
> of course).  (In the end we have a race between our new service running the
> per-user shepherd and our user logging out.  So also wait until a subdirectory
> disappears and kill the corresponding per-user shepherd - if it's still there 
> :P)
>
> A very easy implementation (but not very abstract) would simply hard-code the
> above use case.
>
> A more sophisticated implementation would provide a file-monitoring service
> extension which would allow users to monitor arbitrary files and call a
> procedure once they change (using inotify, fanotify (and stat - because
> inotify can overflow, and then you have to scan manually) under the hood).
>
> * Another way would be to listen to the signal that elogind sends when a user
> logs in or out, which is (see elogind):
>
>         return sd_bus_emit_signal(
>                         u->manager->bus,
>                         "/org/freedesktop/login1",
>                         "org.freedesktop.login1.Manager",
>                         new_user ? "UserNew" : "UserRemoved",
>                         "uo", (uint32_t) u->uid, p);
>
> (In my opinion the signal names are misnomers - sounds like accounts are 
> created
> resp. deleted, which is not the case O_o)
> (In the end we have a race between our new service running the per-user
> shepherd and our user logging out.  So also wait until UserRemoved is
> emitted and kill the corresponding shepherd :P)
>
> * Another way would be to use pam's pam_exec for "account" to start shepherd
> (make sure to switch to the user account first).  Race...
>
> * In the end, all this is special-casing containerization and I wonder
> whether it would be better to have an option for guix environment -C
> which starts a shepherd.  Older UNIXes just abused user accounts
> as good-enough containerization, but that's kinda outdated anyway.
>
> Also, are there user accounts (system user accounts, root etc) which don't
> need a user-specific shepherd?  How to specify those?
>
> As you can see, that's quite a can of worms - and I would prefer it not
> to default to any of those and have the user choose which way (if any) to
> invoke his shepherd.  This keeps complexity down.  (We can document it in
> the manual)
> But can't hurt to have the *abilities* above.
>
> What do you think?

I think this came up last year at FOSDEM, and it would be really nice
to have this.
Furthermore it would be nice to have the ability to specify user
services even on
the os config level. I think one of the usecases discussed there was
to provide a
per user pinentry service for gpg. WDYT?

Also, it seems that some home directory management would be nice, it also came
up several times. I believe that configuring behavior like this should
ultimately belong
there. Also, should this be a per-profile setting instead?

Best regards,
g_bor