Re: [systemd-devel] Creating a fake logind seat with no devices [Experiment]
On Thursday, July 30, 2020 5:00:27 AM EDT Arseny Maslennikov wrote: > On Wed, Jul 29, 2020 at 11:17:51PM -0400, nerdopolis wrote: > > I am pretty much trying to cobble together tmux, cage, and vte, to create a > > full screen VT-like > > console lookalike. (as the kernel one takes input from all devices from all > > seats on a multiseat > > system). Mostly experimental. > > Instead of cage + vte, have you tried the following: > > https://github.com/Aetf/kmscon/ > > This is a fork (should I say, continuation?) of kmscon which builds from > source successfully on modern distributions. > > From then on you can run tmux there. > > Some distros even provide packages: > https://aur.archlinux.org/packages/kmscon-patched-git/ > http://git.altlinux.org/gears/k/kmscon.git > > I can confirm it worked for me as a VT replacement on a single seat and > properly integrated with logind, but I don't have the hardware to test a > multi-seat configuration. > > > (tmux server/client being used to avoid having to start vte and cage as > > root for /sbin/login) > > > > > > The problem is that the tmux PTY running /sbin/login , those sessions don't > > properly create a full > > pam_systemd sessions on seat0, as I get "VT number out of range", because > > as I understand seat0 > > sessions need to be on a valid TTY. Non-seat0 seats don't have this > > restriction, but non-seat0 > > seat hardware is far from a guarantee > > > > > > However I will note so far the only major side effect I notice to not > > having (sd-pam) started in > > this session is, for instance `pkexec` won't work, without sudo. And > > systemctl doesn't try to use > > PolicyKit and whatnot, as from what I understand, that needs to be on a > > session assigned to a seat > > to work I think > > > > Thanks > > > > Hi I wasn't aware that there was that recentish of a fork of kmscon. Interesting. It does run as root though. Now testing with it, it actually help me figure out what I had wrong. I just needed (in addition to Environment=XDG_SEAT=seat0 ) was to set XDG_VTNR=x before running /sbin/login and when logging in a full session with policykit working. (So I was tilting at the wrong windmill thinking it couldn't be done on seat0) However this ends up causing some conflicts, as logind sees it as two sessions on one TTY, and it tries to activate the second one most of the time, so the non-root display server ends up in an inactive state. I was trying an experiment where the display server and the (graphical) terminal emulator could provide something like KMSCON, but not run as root, and provide a valid login prompt. However I realize also that if bad terminal output could get some kind of (theoretical) VTE exploit to run arbitrary code, they will just be able to send commands to start a new session on the tmux socket. So I guess I solved the problem I initially had. Dang. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating a fake logind seat with no devices [Experiment]
On Wednesday, July 29, 2020 7:13:23 AM EDT Lennart Poettering wrote: > On Mi, 29.07.20 00:11, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > 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? > > Seats are a concept of grouping hardware. A seat without hardware > is pointless. If you have no hardware associated with a session then > the session is seat-less, which is totally fine. > > I don't get what you are trying to do? > > Lennart > > -- > Lennart Poettering, Berlin > Hi I am pretty much trying to cobble together tmux, cage, and vte, to create a full screen VT-like console lookalike. (as the kernel one takes input from all devices from all seats on a multiseat system). Mostly experimental. (tmux server/client being used to avoid having to start vte and cage as root for /sbin/login) The problem is that the tmux PTY running /sbin/login , those sessions don't properly create a full pam_systemd sessions on seat0, as I get "VT number out of range", because as I understand seat0 sessions need to be on a valid TTY. Non-seat0 seats don't have this restriction, but non-seat0 seat hardware is far from a guarantee However I will note so far the only major side effect I notice to not having (sd-pam) started in this session is, for instance `pkexec` won't work, without sudo. And systemctl doesn't try to use PolicyKit and whatnot, as from what I understand, that needs to be on a session assigned to a seat to work I think Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating a fake logind seat with no devices [Experiment]
On Mi, 29.07.20 00:11, nerdopolis (bluescreen_aven...@verizon.net) wrote: > 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? Seats are a concept of grouping hardware. A seat without hardware is pointless. If you have no hardware associated with a session then the session is seat-less, which is totally fine. I don't get what you are trying to do? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating a fake logind seat with no devices [Experiment]
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-_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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
