[systemd-devel] Creating a fake logind seat with no devices [Experiment]

[nerdopolis]

Hi

Sorry about the length.

I have a unique thing I am trying to solve, is that if I have a service that calls /sbin/logind under
something like tmux, and I set `Environment=XDG_SEAT=seat0` in the service file, upon logging in, 
pam_systemd fails to create a session, as it's seat0 and it's expecting a valid TTY number, as it's 
seat0. One of the side effects is that you lose the credential prompt that you usually get if you 
run a command like `systemctl restart foo.service`, and there could be other things too?


On a QEMU multiseat system, if I instead say set `Environment=XDG_SEAT=seat-pci-pci-0000_00_04_0`
pam_systemd works, as it's OK for non-seat0 to have a session with a TTY of 0, the (sd_pam) process
runs, and privileged systemctl commands do the text mode prompts for authentication.

The question is is that most systems are not going to have the hardware to create a second seat, as
it seems that the only way to create a second seat is to have a hardware device tagged as 
master-of-seat in the second seat. Which is probably very rare. If I say set 
`Environment=XDG_SEAT=virtual` it fails because that seat doesn't exist.


Is there a way to create a fake seat to start this service on? Or make an exception somehow to allow
that session to not have to be on a 1-63 TTY? Or is it irrelevant as it's mostly for granting 
permissions to input and output devices? Although with out pam_systemd You do lose the text mode 
Authentication prompt for some systemctl commands, but I can't think of anything else. (except maybe 
that if your main session is playing sound, and then you switch and log into a TTY, you can hear the 
sound play again)



-----------------------------------------------------------------------------------------------------
And in case if you need to know why I am asking this, for context, I am doing some experimenting with 
making a jerry-rigged vt experiment because of
https://github.com/systemd/systemd/issues/15387 and https://bugzilla.kernel.org/show_bug.cgi?id=208239

It's just a collection of bash some scripts, and .service files that call an instance of tmux with
lots of bindings turned off as root (which calls /sbin/login), grants a restricted system account 
access to the socket files, and then vte running under cage that runs as that account, and runs a tmux
client that connects to the socket, but it's just an experiment.

(And obviously needs kernel mode setting, although with those particular problems, I guess it will be
irrelevant if you have no mode setting in the first place.) 


(Maybe I am going at this the wrong way, as both the Display Server session, and the guest session will
BOTH need to be active, and that's not possible)

Thanks