From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id 100E026D88 for ; Mon, 15 Jul 2024 01:01:48 +0200 (CEST) Received: (qmail 23370 invoked by uid 89); 14 Jul 2024 23:02:13 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 23363 invoked from network); 14 Jul 2024 23:02:13 -0000 X-Virus-Scanned: Debian amavisd-new at web14.point.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sopka.ch; s=default; t=1720998104; bh=3JLPkvTaHF9zAeerop83RYL08yDQ+xoZmPP1K0BgQGw=; h=Received:Received:Subject:To:From; b=UYTHSf+CwJVrZj9isT5lT2DyEI+2INrDUouH5jx09ZIwUPefoRFcU6RfSg/pGy4Wl 1lWqYzOtPVGPkh0+HOh+oALw/fXGZs2/J0BtB3pKPbHBw9PS9ZYvq0ECCBMROnpdpO BP9jXPgMNrlBJUV/cXcS9zVgtPHk95xR7dBWw348JfQKZyVx1XsvWD5wmo1Shkd0FI QE6wtpKgQsuMJ4tIzi51YnF5P4/FbRQg1sNxhNfZb42vZsq225DaYuPV0Q1tdDzVwn c/Pi3hm/pv8eTbVypJMoqAhgfnR74JUOeHlnsCex1YolV5RpdA5+eLTszlRQfixExz HEwUXzTaznqCA== Authentication-Results: plesk.origon.ch; spf=pass (sender IP is 127.0.0.1) smtp.mailfrom=psopka@sopka.ch smtp.helo=plesk.origon.ch Received-SPF: pass (plesk.origon.ch: localhost is always allowed.) client-ip=127.0.0.1; envelope-from=psopka@sopka.ch; helo=plesk.origon.ch; Authentication-Results: plesk.origon.ch (amavisd-new); dkim=pass (2048-bit key) header.d=sopka.ch Received-SPF: pass (plesk.origon.ch: connection is authenticated) Content-Type: multipart/alternative; boundary="------------mr3tIydOH3tnseCxnbEOazKB" Message-ID: Date: Mon, 15 Jul 2024 01:01:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification To: Carlos Eduardo , supervision@list.skarnet.org References: <3ed2cd6a-660b-4a3d-b456-584650790f4c@sopka.ch> Content-Language: de-DE From: Paul Sopka Autocrypt: addr=psopka@sopka.ch; keydata= xsFNBGW5FlEBEACi9wDm7vnwoxMy6ejpZQh2Z1Mpr4fTKJyWLn3sZFAjmQKcsT/ORt0rVSBO 5eXoGjbk5Hor2l67mui85a4KWawHbYFC95hpA9K/alfGyQH56SnL5G55DDcz3avkLrJ9bHJD 4y4ScEzweYW2IjYr90FKqZWWcdqzYDqmqRtf5/rdkmY6YVtpBISIfYNbBRPE3CJuY7HOpQ4s qAmb5iRsXN38hv7UQj9MsJl5Q0cxgcFcRGy9dAM5voX1Xh+h9svS1MZuaxzyLR0YvCzAcY8c 7uUsXjj67/NmeHpl5pYHiT19g/wcHbudYLI+pikx4EcskinZ1peZbrbBdVdBeOtukBzaMuFe dOcSpAWbDDK7e4cwZnPse130FjNECzIrNAB2lK2rb9f2PCyZSRCW7QBG63IUREWZTLBm47Dy avMzh+wGV6Jx6kigdngJDtIXXDzw2ZWAMMT2MEPX4HC1POH8b1DZ/QxzC+2SQbJNfrQitm0K kOo8o2gqMpuBABAYzQwRJXNteeW5ZccbgdQ0+m61kV/P71bmeiasvJGyecxzOfRUDei7b3Lh 8O5xPHP1dq23E9R76fCaCCiutfiZT5zT5dbn8XGqBmKI9z8VGEfCBdFbopZd4fpQPmVNWlR0 yrM7DnHST1OJtGZ2/gwk0Py2dO+lbZDQMqVRVYXT1dYenwYa5QARAQABzRxQYXVsIFNvcGth IDxwc29wa2FAc29wa2EuY2g+wsGUBBMBCgA+FiEEklpwGqZx1YzBW1hqccfIWi6jD2IFAmW5 FlECGwMFCQeEzgAFCwkIBwMFFQoJCAsFFgIDAQACHgUCF4AACgkQccfIWi6jD2KbNw//QSMh 6QRTxCRHVJGp4vHAz6hWt/zimRbVkO0t4Q/5uXClRnMzZqqE+TLubNRy560Y/LxuQ4phB/O4 mcHRqbV9Xrarx98jWNqMgsGhD60W3uxr6RRObeB0+PpRHVhzzqAMtWh6OZGQ9+vJJf3Q4Axw o/cafNgm2V0MOWsVFUxUVUbDsR8aZP7RyDRJRv5v6T4pu4Jjd9BH+UxfsG5dvE2Jqj4/a5OI cJ0XlMSkJxHorDjxLGNFJ8pTcH3/Y7eWmPL0U6kKS99ol763V5LEOnQnqpbwqCalwumgYoXw HCahiZlmX2Zl4omf9zHvgzADk66rNvZUvBAIMXDWAoWjL9IxxqTIVUjJk0cv3jN8fZc309s4 0jDQze3LDSCp9+7SP//jlgADsvfUxJemvoqDYpANrt/wEZ9lxr5doi0R2CEPbfPkmWyaGUcF BdlVAaYCL5Sg++OfyjCeu4MAC1JZfHOBjQbzwKhG4MqZs8O1Snr42JvbyzonDckl7UJUZwCh UPO4GrFu8zQxqa2ZDx/zok6+bMD0ggDXj6svGUzGqMxOr4bJa7MxUQ1iIXYl0WTEFbTT9GTi 3nxXt0ZPyHN1f9GXgGAB5Qc8hpgm6VFewjeohNvaxOpcMCXBYWX9DcuNuKMwofOpGV2hse3b Owy13+ci7sb/A2RBC0wBKV/20iuLxFrOwU0EZbkWUQEQAMMWfQpVgrSLCMspW5lkjvl+0Bz1 XurJzUF9OcLP2DSRHEuYNlc+XBvPxh1F3vJfv1Ts79ayDi7YQn+sVTtkGja2RnzXIzrfnodg Ye4F71mW9IjYN6Pl3oUBCBB8vJt1oTwNfRugLGP0ZA5T8ntHP3ryUnBlSr3rTQp8JuOJ/9An thWDHHoP8qIy9HNDdinDNVpHhGJ4w4CtM2QwFh33ZYXY7qFGOwKdnU1AehJ/Ld5O/XIVPHma NGuWgXKVlvrCejifD03cRfbwqQA08VQk6/8rLco25EXpKKfqZpKQHibFTvNF0bKWs7RhFmHq qzqxAWTsXK/S9yOpbad/HShHBpDiKtyit2zaU+DBg2JsHW1KtISO6ssYyQ1yN8THF4xbOO1x T/bGsfZKC16bZHG9nemzDgcR05recLvZrti8z+55GHL19SJzVAKZ4TdX/2MGIfPoywMcrs5O IswzIWILz9KwmhqlFop3MzG0Fmv7dxW9Zf3MFd0Zw1BwuQxm0D1+gFHViuhRi803Stfb9qP+ CwSNwsjAQznMFeFKKO/S6yWpK0bMxt3Io09+rlW/rwhPwl/j8Xwcynr9PDhyBbjhsM30tNzL vJyy0l8aF+GBGX9JcqjHU1bxM1RQTDHJI1erJaaySZzKqdjYVI/4buGCsUt2lJds6jyy/GPT ZKGV9iALABEBAAHCwXwEGAEKACYWIQSSWnAapnHVjMFbWGpxx8haLqMPYgUCZbkWUQIbDAUJ B4TOAAAKCRBxx8haLqMPYjOmD/9UjqgchWIApSbllaT+o+rf2ZSDVCCcMnv6sVzs04dAGtn9 EyUueishIsbOOH11eRpwnQOMoK4/7MltnRIf0ksX9uho7pDtpPJfveQIKZ+sTwpOdiy1yQdl T2j1RDtzph+v96KEqa7B9AI4F/34/0a86OJiLs85ystwMw2mTxiz6Qi0W+nCSxpJr1s1HVfl tzkU8ggXfeas0o955VoSHkgwDTjT+gw75nOX/26kMjFQ8zImWPIf/jvPhq+9yMBuP0iQS+hs 1m8xQ7Gd7tG2I5G6kLGEack3bphGzlsPatSznHi6rnmzVOQI3/vag7oXvNJI6GAZMIUQ5h+l NbGnOBb/M3inTVgyJruNP7Q1fPIUHG++/5DXWP1uuKJxYGGI/As2tz2lHbWzP7y6jaJvBBjG qPk8JwBfK98JSH4VvJStF9Ga+QFCCXb2TUeIIS/mVQ3gAln0g2hsZ0QsMvuohk300noV97Yn XEKGUXKwOnfpHAxCYreqzMHInyDm6YciMR2JADhB5tS7KUWmQP2j0lYrEZZJmZ+bu9Edrv/v 67mNDnzCANN1UhuoKODK2Wijcmbtu/7d78SBzxTEjh3RXMZKLS57N78fNnEGnuF9IS9vOU43 y5QCmGCCZsf/r5d5hx2yxqrNInoPiGuY64XUMJXfFbA36ZPoLsvxoK0+8QRhtw== In-Reply-To: --------------mr3tIydOH3tnseCxnbEOazKB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I am resending this unsigned, since the message is too large otherwise. > - `/run/turnstiled/sessions` exposes similar data as your proposal's > `/run/session` folder (including being able to query the session type). > Take a closer look at the prior art before writing it off. Thank you for pointing that out. To my defense, this is neither mentioned on the Github page (https://github.com/chimera-linux/turnstile) nor in the manpage. Sorry if I have overlooked something. Anyway this is not what made me start creating this alternative. My main reason is that the way my solution currently handles it, allows: a) for different bundles to be started for different types of logins. b) integrates better with my approach of handling the user service trees with instantiated s6/s6-rc services. c) for less overhead and is way simpler e.g. not having to have a daemon running all the time. > - Just the session data isn't enough, as you need to patch third party > software that relies on it [3]. Turnstile (or, really, any proposal that > doesn't assume a specific setup of the underlying system) allows sharing > this load with other distributions. > [3]https://github.com/void-linux/void-packages/pull/44676 Those are mostly patches to Turnstile, and changes to files in /etc/pam.d which, as config files, are distribution/system specific anyway. There is one patch that is not about the above is a patch to polikit. I need to investigate whether this is needed for my solution too, since my knowledge about polkit is limited. I still need to test all the greeters, but agetty and ssh work like a charm. On a sidenote: I run everything that I am seriously proposing on my daily system. This includes the proposed session management script. > - Expecting the user to directly edit scripts if they want different > behavior, instead providing some degree of built-in configurability, is not > reasonable for a packaged solution, as even the smallest user tweaks would > be in constant attrition with package upgrades. I completely agree, I have stated (twice) that this is a very crude version. I only posted this to see whether there are any fundamental flaws with the idea. The statements about extensibility, e.g. > - Possibly create a /run/session/${USER} directory. Were more about what I am considering to add. Of course I will refine the script and add configurability. I am also thinking about turning it into a little PAM module itself to allow it to export environment variables to the user's shell. > - Without a daemon's mediation, processes writing to the database have to > coordinate themselves with locks¹. This introduces risks and limitations > you don't want to have when said writes are happening without human > oversight [1] [2]. Turnstile is a daemon for a good reason. > [1]https://skarnet.org/software/s6-rc/s6-rc.html (-b option). That's why the option -b is here, the example of nested invocations should not be able to happen here, if I understood correctly. > [2]https://skarnet.org/lists/supervision/0391.html Doesn't s6-rc -b perfectly solve that for this situation? If not, why? > - I won't repeat myself on why a system that relies on calling the current > generation of s6-rc upon receiving events, or processes meant to be running > in different contexts sharing the same supervision tree, especially one > with only a boot-time environment, are a bad idea. Go ahead and actually explain, please. You will not repeat yourself, since, up until now, you really only stated that you are considering it a bad idea. > I've already explained why this is not true unless you want to force the > project out of its scope, and how it's an infinitely more accurate > description for your proposal. Neither did you actually explain that. Please do. I will go into detail on why I think the opposite is true: If we have a group of maintainers responsible for the s6/s6-rc profile, they need to monitor s6/s6-rc closely. In addition to writing and fixing service scripts that is their job. My proposal, in it's current form, adds 4 additional scripts to that, which is not exactly "out of scope". Relying on Turnstile, which to my standards is tightly integrated, requires quite a few things to be done in "the Turnstile way". I am not saying that the latter is bad! This on the other hand naturally requires synchronization between the Turnstile package and whatever provides the user service tree defaults. Which will result in either the Turnstile package having the same maintainers as the s6/s6-rc profile or at least requiring both maintaining groups to have a good connection. I am not saying that any of this is necessarily bad, but it is causing more expenditure. That said, even if it took a bit more effort to maintain my solution, this could be justified by the expanded functionality of per login type bundles and boot time user services. > Instead of reducing scope and relying on a loosely coupled third party > solution, you're making a solution that marries session tracking to a > specific policy for a specific init system. > [...] you're making a solution that marries session tracking to a > specific policy[...] In that sense doing it the way Turnstile does also "enforces" the "Turnstile policy". I don't see where Turnstile has the advantage here, since it's "service manager/init system cross compatibility" results from service manager/ init system specific backend scripts which, in terms of complexity and length, are in a similar scope as my solution. > [...] for a specific init system. This is wrong. The usertree can be prepared by any init system, the script itself is tied to s6-rc for the user services, but the same goes for the Turnstile backend. From what I have seen of dinit, my script in its current form would require exactly two lines to be changed to be used with dinit based user services. Finally, I want to address another point: > Not to_the_, but to_a_ login session. Whenever turnstiled is informed of > a log-in, it loads the PAM modules in /etc/pam.d/turnstiled, and runs > `backend run ...` as the shell. You can confirm that with a pstree; > dinit/s6-svscan are children of an intermediate "turnstiled" process, not > `login`/your display manager (see [1] for why replicating this directly on > top of a supervision suite is more trouble than it's worth). > > [1]https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html, > section "PAM changed everything". And, from the mail before (https://skarnet.org/lists/supervision/3138.html): > Under your design, the process that authenticates the user and has all > the information provided by PAM (or an eventual replacement) will be > unrelated to the user supervision tree (in the sense that the > supervision tree will not be forked off from it). This is a fact. > > Turnstile requires the service backend not to be a oneshot to ensure > the supervision tree is a child of an actual login session. The more I think and learn about this, the more it appears merely as a cosmetic point: Why should the user supervision tree being a child of the turnstiled process be any better than being a child of a "dynamic instance s6-svscan"? Also, from the mail before (https://skarnet.org/lists/supervision/3138.html): > Turnstile's PAM module does that, synchronizing these in the login > process to be the same ones as in the supervision tree the daemon > spawns, and unless you want to make users replace their shell with > something like `/etc/execline-startup` as described in > https://skarnet.org/lists/supervision/3126.html, your proposal is > going to need a custom PAM module for that too. This is wrong. Turnstile only exports a couple of environment variables: > The backend is a little helper program that can be written in any > language, it can e.g. be a shell script. It is started with a clean > environment with many of the common environment variables, such as > |HOME|, |USER|, |LOGNAME|, |SHELL|, |PATH| and others, freshly > initialized. (from the Turnstile Github here: https://github.com/chimera-linux/turnstile) As well as possibly ${XDG_RUNTIME_DIR} and ${DBUS_SESSION_BUS_ADDRESS}. One is once again limited to what Turnstile offers by default. Except by sourcing an env dir/file in the backend script but this causes exactly the synchronization needs that I want to avoid and that you criticized. My proposal on the other hand, starts the user service tree from a simple s6 run script, being able to use the same env file/dir for the creation of e.g. ${XDG_RUNTIME_DIR} and as an environment passed to the user services as well as by a potential pam module that exports it's content to the users shell. This env file/dir can be freely changed and adapted by the sysadmin, since it is sourced as a whole. > You can confirm that with a pstree; > dinit/s6-svscan are children of an intermediate "turnstiled" process, not > `login`/your display manager (see [1] for why replicating this directly on > top of a supervision suite is more trouble than it's worth). > > [1]https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html, > section "PAM changed everything". I don't need to replicate that, because I am already doing the same, just that the parent is "dynamic instance s6-svscan" instead of "turnstiled". Sorry for citing the old mail, but these points are so closely related that I found it to be more complete in this way. Have a nice week! Paul --------------mr3tIydOH3tnseCxnbEOazKB--