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
Received on Mon Jul 15 2024 - 01:01:39 CEST