From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#33260: Invocation of per-user shepherd - design needed Date: Mon, 5 Nov 2018 08:58:26 +0100 Message-ID: References: <34806e19-072a-ce32-3a23-78e78f59b719@riseup.net> <20181105015535.177655c9@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJZyD-0000sn-NY for bug-guix@gnu.org; Mon, 05 Nov 2018 03:10:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJZmo-0005T3-FT for bug-guix@gnu.org; Mon, 05 Nov 2018 02:59:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:58520) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJZmo-0005SP-9a for bug-guix@gnu.org; Mon, 05 Nov 2018 02:59:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJZmn-0007Kq-Uu for bug-guix@gnu.org; Mon, 05 Nov 2018 02:59:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20181105015535.177655c9@scratchpost.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Danny Milosavljevic Cc: 33260@debbugs.gnu.org Hello Danny, Danny Milosavljevic ezt =C3=ADrta (id=C5=91pont: 2= 018. nov. 5., H, 2:04): > > Hi, > > this is a known problem in GuixSD (not in shepherd) and I don't think any= one fixed > it yet, because it requires some design (and is kinda harder than ignorin= g 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 do= n't > remember huge shared computers which you would dial into multiple times f= rom > 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 fo= r the > first one for this user - so only one shepherd per user will actually sta= y running. > > This is a simple way to do it and I prefer it to any more complicated sol= utions - > since it's in the unix spirit of "worse is better" (in this case: non-sar= castic). > > (For a more universal (non-fluxbox, it's too old) way, use ~/.config/auto= start > 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 eve= n 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 process= es > 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"). (Thi= s > would break Screen if not started right away with the session, though) > In any case, the "simple way" above works when KillUserProcesses=3Dno and > also when KillUserProcesses=3Dyes, so for me problem solved ;P > > (Also, traditionally UNIX would kill the controlling (that is, first) pro= cess > that was started in a terminal once that terminal is disconnected (kill v= ia > 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, b= ut > 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 t= he > per-user shepherd and our user logging out. So also wait until a subdire= ctory > disappears and kill the corresponding per-user shepherd - if it's still t= here :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 servi= ce > 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 sheph= erd > (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 c= ame 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