List of open questions

[matu3ba]

trafficstars

1. Logind requires PAM to be used anyways so probably some PAM module will be used to authenticate a user when he logs in.
2. How exactly multi-seat is done in udev-rules is not clear to me.
3. If anyone can shed light on what some of the more mysterious parameters do please let me know!
4. I am not entirely sure why this is necessary info to the session manager, but it is not entirely weird. Maybe a session created by some PAM module need special handling.
5. How are sessions created that are not user?
6. I don't know what this is for. Remember this is called by the systemd_pam module. Why does that need another way of communicating with logind?
7. since (hopefully) all input device filedescriptors have been handed to the session through logind -> Can we check the cgroups for unassigned ones?
8. "posix sessionids in most cases. But those are not reliable since processes can leave their session and make a new one." Why can we not forbid this to simplify things?
9. "That is why logind pushes the first process into a cgroup right at creation of a session." Is there a naming scheme of the cgroups?

[KillingSpark]

I have answers to some of these, I will update the text to include/clarify these.

1: I don't think it is necessary that PAM is used, it's just what systemd expects and they provide the pam_systemd module that does 'all the right things (tm)'. I am pretty sure one could do 'all the right things (tm)' in any other login/session framework, provided one knew what that actually meant.

2: That one is a bit tricky. As far as I understand it, the system-admin would have to write some udev-rules that assign the different devices to the correct seats. I left that a bit open because I am not sure myself. Maybe there are some cool automagic tricks....

7: I am not sure what you mean here, unassigned input-devices or unassigned sessions? Either way I think it would be best to track this explicitly and not rely on wonky cgroup hacks to get the info.

8: It's just how the sessions in posix work. I think they were meant for (and are used for) things like shells, so they can make their own sessions, have foreground and background tasks etc... I dont think they were meant for reliable process-grouping. It is very useful to able to do this, so shells can spawn new, independent shells.

9: Yep! They are systemd-scopes in the users slice. /sys/fs/cgroup/unified/user.slice/user-{{UID}}.slice/session-{{SessionID}}.scope For example, the session I am currently writing this from is: /sys/fs/cgroup/unified/user.slice/user-1000.slice/session-2.scope/

[matu3ba]

2. can be done significantly simpler as shown by seatd. It remains to see how complete the implementation is, but so far it is looking very clean and used by Sway and river.

[KillingSpark]

Could you explain how seatd determins which device belongs to which seat? A comparison with other tools in this space would be a cool addition to the text.

[matu3ba]

I checked and found out that this is not yet implemented, lol. -_-