From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#33260: Invocation of per-user shepherd - design needed Date: Mon, 5 Nov 2018 01:55:35 +0100 Message-ID: <20181105015535.177655c9@scratchpost.org> References: <34806e19-072a-ce32-3a23-78e78f59b719@riseup.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/.x9twJO0vlUo5yTXCXUf1iD"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJTJk-0005tu-Dn for bug-guix@gnu.org; Sun, 04 Nov 2018 20:04:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJTBT-000095-PU for bug-guix@gnu.org; Sun, 04 Nov 2018 19:56:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:58414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJTBT-00008x-LU for bug-guix@gnu.org; Sun, 04 Nov 2018 19:56:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJTBS-0005cd-GK for bug-guix@gnu.org; Sun, 04 Nov 2018 19:56:03 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <34806e19-072a-ce32-3a23-78e78f59b719@riseup.net> 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: swedebugia Cc: 33260@debbugs.gnu.org --Sig_/.x9twJO0vlUo5yTXCXUf1iD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, this is a known problem in GuixSD (not in shepherd) and I don't think anyon= e 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 solut= ions - since it's in the unix spirit of "worse is better" (in this case: non-sarca= stic). (For a more universal (non-fluxbox, it's too old) way, use ~/.config/autost= art and put a "shepherd.desktop" file there) This assumes that nobody will clean up session processes when the session e= nds, 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=3Dno and also when KillUserProcesses=3Dyes, so for me problem solved ;P (Also, traditionally UNIX would kill the controlling (that is, first) proce= ss 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 subdirect= ory disappears and kill the corresponding per-user shepherd - if it's still the= re :P) A very easy implementation (but not very abstract) would simply hard-code t= he 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 us= er 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 cr= eated 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? --Sig_/.x9twJO0vlUo5yTXCXUf1iD Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlvflQcACgkQ5xo1VCww uqUuWwf+NRntpBvy0cE3qjqi17BJeIaW+g6ypjfW0yVvCz8//r49RsmbOty8POEg plr8JM6l39hiUY9avQyUMeLvNGeDKfYhpQoG3Sak2ipmuOXSXjgjKKJmkMdpYCFB GWJnQkuIgSeIjoDArk8olDNdKP1MKlMyTzPFbqxw+pCngdKWT/8aImuodjc8JA16 RNomrT67zd5Zeh56sQxz2lcEzNs0BKHVaIkm5pDGoypU84zNVOztfqVPK44EnIdc BAIShCR80JPO42e2aMkfZ3HWjy+zOa8isLWIAYrosWgSwukha0UrkCvPfOUSHGhL Ue3tAxlBZaP2S33kNZ8aZYgTd9+y4A== =eJ3U -----END PGP SIGNATURE----- --Sig_/.x9twJO0vlUo5yTXCXUf1iD--