Strategy towards specification of Linux session layer (and Unix)

[matu3ba]

trafficstars

Hey @KillingSpark.

1. seatd is soon getting used by Sway for the seat abstraction. I cant find the commit and issue for now. :/
2. PAM manages the user authentication ie Linux PAM and is invoked by systemd as module.
3. Do you know how much complexity in LOC session manager implementations have?
4. So as far as I undestand systemd's main purpose is tracking program status (and killing them on misbehavior) as explained in watching for exiting sessions. Or where am I wrong on this?

The manipulation of stuff is given by Linux API and should be separate-able from systemd.

[KillingSpark]

I am a bit confused by the title of this issue. Are there efforts somewhere to create that spec? Or are you trying to start this effort? Anyways here are my thoughts towards your points.

seatd is soon getting used by Sway for the seat abstraction. I cant find the commit and issue for now. :/

That's neat but as far as I understand seatd's vision sway should just use libseat which can interact with both logind and seatd, so sway would be able to run on both kinds of systems. And I think this is a very good thing have. The shells really should not depend on the concrete seat managing software used on the system, if it is avoidable.

PAM manages the user authentication ie Linux PAM and is invoked by systemd as module.

It's the other way around. The login calls PAM to auth the user. Then a module pam_systemd.so is called into after the auth was successful. This creates the session slice and puts the current process (running the PAM) into this slice. This causes all further children of this sessions initial process to be in this slice too.

On the other hand, systemd does spawn the login so it is kind of a circle at this point.

Do you know how much complexity in LOC session manager implementations have?

Nope, sorry.

So as far as I undestand systemd's main purpose is tracking program status (and killing them on misbehavior) as explained in watching for exiting sessions. Or where am I wrong on this?

I guess that is a very short description of its function in the context of session management. It does however have a lot of other features that are unrelated. Timers, socket activation and managing a network of inter-depending services are among those features.

The manipulation of stuff is given by Linux API and should be separate-able from systemd.

I am not sure what you mean by this. It is of course possible to do what systemd does without using systemd. It's not magic. It is a lot of work though. Replacing systemd would be a big undertaking. (believe me I know what I am talking about :D)

If you dont replace systemd you'll run into some other problems though: systemd becomes unhappy if you start fiddling with the cgroups it manages. So using something else to manage sessions while systemd is running is going to be weird. You'd need to have your login run outside of a systemd slice. I don't even know how that would work because the login itself is spawned by systemd.

[matu3ba]

overall way of how stuff is started: login manager ->PAM-> session manager -> window manager (start, resume or stop). Without session manager one has login manager -> window manager and hard kill of applications (potential data loss, since applicactions are not be able to write data in time).

KDE uses ssdm: "Simple Desktop Display Manager (SDDM) is a display manager (a graphical login program and session manager) for the X11 and Wayland windowing systems."

Gnome uses gnome-session, which works as sketched: login manager(either gdm, xdm, or from your X startup scripts) -> gnome session -> window manager.

I we take the Login manager(LM) = logind -> Session manager(SM) -> Window manager(WM) adding systemd looks roughly like this:

1. systemd starts services LM+PAM+SM by startup dependency + monitors if program is fine + does event-based IPC.
2. LM asks PAM if user has permission to start/resume/stop session. Waits in the background to handle stuff.
3. PAM does what it is told to http://www.linux-pam.org/Linux-PAM-html/sag-overview.html
4. LM tells SM to start session with hashed authentication info.
5. SM runs configure scripts to setup WM and WM itself. Waits in the background to handle stuff.
6. WM does WM-specific stuff.

So logind is kind of redundant, but probably can do stuff more efficient with systemd.

[matu3ba]

@KillingSpark Dynamic dependency resolvement is a hard task, but its kind of related to borrow checking in Rust where you must give an explicit lifetime order how stuff is started and stopped.

Why is this not feasible to do generate a static lifetime resolvement and hotswap the binary that manages the services?

[KillingSpark]

Funnily enough, what they describe as a session manager is not what logind is. They mean the program that actually sets up the user shell (be it startkde or gnome-session or whatever). Logind is only ever called from the PAM module and does explicitly not start any window managers.

So logind is not redundant, it provides additional separation between sessions, that the normal login process you described does not automatically include.

Dynamic dependency resolvement is a hard task, but its kind of related to borrow checking in Rust where you must give an explicit lifetime order how stuff is started and stopped.

Why is this not feasible to do generate a static lifetime resolvement and hotswap the binary that manages the services?

I don't think that's how it works. To manage services you need to assume that they misbehave, that they die early, and handle that appropriately. This means you cannot do this statically, you need to manage that dynamically at runtime.

This is not really related to lifetime management. Lifetimes are more or less information about the "scope" of a variable, which lets the compiler check if accesses to these variables are valid. On the other hand the dependencies between services include explicit modelling of a before/after and a wants/requires/wantedBy/requiredBy relation.