[systemd-devel] logind on VT-less kernels, and starting a greeter on session hangs
While on VT-less seats, while all major Wayland compositors support CTRL+ALT+F(x), the drawback is that on VT-less seats and kernels, it only works when there are multiple sessions on VT-less seats to switch between, as most display managers stop the greeter when starting a session, and a large majority of the time, only one user is logged in at once. I am thinking mostly of if the session hangs, or when kscreenlocker crashes on KDE, and it instructs the user on how to login to start another session. (Also, this can happen now, but in instances where the compositor becomes totally unresponsive, the compositor or session no longer is able to handle the Ctrl+Alt+F(x) keys, and running commands then requires a remote SSH connection) I am thinking a rescue key sequence that logind itself could listen for (since it already seems to be handling some other keys like Sleep and Hibernate keys), and then in turn maybe emit a Dbus signal that login managers will respond to, and switch to or re-launch the greeter on the seat that the key sequence was pressed on. There is also the question on what key command it should be, In my mind pressing and *long holding* Ctrl+Alt+Esc seems the most logical, but then that would mean logind would get woken up every time Ctrl and Alt is hit, and that could have a slight impact on battery usage. I was also thinking pressing and holding Caps+Esc? It has to be keys on most keyboards, and it seems *some* laptops manufacturers made it their mission to not give many options. What do you think? Or is this outside of the scope of logind, and should the display manager do that instead? Thanks
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Friday, May 28, 2021 3:13:17 AM EDT Pekka Paalanen wrote: > On Thu, 27 May 2021 17:33:35 +0200 > Lennart Poettering wrote: > > > On Sa, 22.05.21 13:50, Pekka Paalanen (ppaala...@gmail.com) wrote: > > > > > All in all, this stack would replace the usual stack where > > > /bin/login runs directly on the TTY of a VT, allowing to use a more > > > featureful terminal, custom display modes, multi-output support, > > > maybe multiple parallel sessions for different users a la fast user > > > switching, and more. > > > > When you say /bin/login do actually intend to say "getty"? what is > > /bin/login good for here? it's a stub that expects you already give it > > a user and it then only asks for a pw. It's the second part of a getty > > pretty much. > > Yes, sorry. I'm not clear what any of them actually do. Hence, please > replace everything I've called "the login program" or similar with > yours above. > > Odd, maybe the /bin/login that ships with Debian does something not standard then, because, that one does prompt for a username... https://i.imgur.com/hEw941h.png > Thanks, > pq > > > > We have multiple services that you can instantiate on ttys, for > > example getty@.service (for true VTs), serial-getty@.service (for > > serial ports), container-getty.service (for /dev/console), > > container-getty@.service (for gettys on pseudo TTYs, pretty much). > > > > It appears to me that the right approach for your case is to do what > > container-getty@.service effectively does and instantiate an > > appropriate instance of a template service modelled after it for the > > "other" side of the pty your terminal app allocates. > > > > Instantiating -getty@.service requires privs, but you can use > > polkit to grant that to your terminal app's user. THe polkit auth > > request carries the unit name as additional metadata, hence that > > should be pretty easily done with some minimal polkit JS. > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Thursday, May 27, 2021 11:33:35 AM EDT Lennart Poettering wrote: > On Sa, 22.05.21 13:50, Pekka Paalanen (ppaala...@gmail.com) wrote: > > > All in all, this stack would replace the usual stack where > > /bin/login runs directly on the TTY of a VT, allowing to use a more > > featureful terminal, custom display modes, multi-output support, > > maybe multiple parallel sessions for different users a la fast user > > switching, and more. > > When you say /bin/login do actually intend to say "getty"? what is > /bin/login good for here? it's a stub that expects you already give it > a user and it then only asks for a pw. It's the second part of a getty > pretty much. > > We have multiple services that you can instantiate on ttys, for > example getty@.service (for true VTs), serial-getty@.service (for > serial ports), container-getty.service (for /dev/console), > container-getty@.service (for gettys on pseudo TTYs, pretty much). > > It appears to me that the right approach for your case is to do what > container-getty@.service effectively does and instantiate an > appropriate instance of a template service modelled after it for the > "other" side of the pty your terminal app allocates. > > Instantiating -getty@.service requires privs, but you can use > polkit to grant that to your terminal app's user. THe polkit auth > request carries the unit name as additional metadata, hence that > should be pretty easily done with some minimal polkit JS. > > Lennart > > -- > Lennart Poettering, Berlin > I guess I meant to say getty, but getty ends up calling /bin/login anyway after resetting the terminal and reading /etc/issue anyway. Or at least I thought. Interesting I found some simple enough looking samples for granting users the ability to start one service. Dang, it might not work with Debian's fraken-polkit-0.105 they still have. I am able to tweak up a test copy of container-getty@.service, setting TERM to xterm-256color and doing the XDG_SEAT=seat-vtty workaround so the logged in session has PAM too, and nmtui doesn't do this https://i.imgur.com/dt7xAMz.png so that works. Something like that is what I was originally looking for, so thanks! but I will admit, one thing I've come to like about the socat client/server hing is that if say cage or vte takes a segfault during say an apt-get install, the running command doesn't die... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Thursday, May 27, 2021 11:23:44 AM EDT Lennart Poettering wrote: > On Fr, 21.05.21 21:29, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > On Thursday, May 20, 2021 10:53:24 AM EDT wrote: > > > On So, 16.05.21 19:41, nerdopolis (bluescreen_avenger at verizon.net) > > > wrote: > > > > > > > Hi > > > > > > > > I am trying to experiment around replacing the text mode TTYs with > > > > usermode > > > > utilities. > > > > > > I don't follow? > > > > > > > > > I am sorry, I will try to be more clear. That first email, went through > > several > > drafts, as at first it was longer and rambly, and I didn't want to bombard > > the > > list with a giant wall of text. > > > > > > (I actually found my solution was to use socat since sending that last > > email.) > > > > > > I was seeking some more existing programs I could try to cobble together to > > come up with a solution. The main things were: > > I still donÄt get what the "end goal" is. You start with the tools you > want to reach your end goal, but never specify what precisely that end > goal is. > > Do you intend to replace the Linux VT with a userspace implementation > of the same concept? > > Or do you want to run a full-screen graphical terminal app on one > Linux graphical VT that behaves like a text VT but renders stuff > graphically? > > Lennart > > -- > Lennart Poettering, Berlin > Sorry I wasn't clear, it's a full screen graphical terminal that behaves similar to a text VT. I replace autovt@.service with the front end service that starts the instance of the display server, and the terminal emulator. I imagine replacing the whole VT would entail more than a full screen graphical terminal emulating it... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Saturday, May 22, 2021 3:14:27 PM EDT Pekka Paalanen wrote: > On Sat, 22 May 2021 09:04:42 -0400 > nerdopolis wrote: > > > On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote: > > > On Fri, 21 May 2021 21:29:09 -0400 > > > nerdopolis wrote: > > > > > > > Sorry, I got the terminology mixed up again. I am still using TTYs to > > > > run the > > > > instances of `cage`. It's the kernel mode VT emulators I am replacing > > > > with the > > > > user mode terminal emulators (running under a fullscreen Wayland > > > > compositor) > > > > > > Hi, > > > > > > I'm trying to clarify things for everyone here, since I think I can > > > guess what you want to achieve, but you have a hard time explaining > > > your original goal. I hope you don't mind. > > > > > > > > That's fine. Thanks! > > > Starting from the outermost "layer" and going inwards: > > > > > > 1.a Have a system service, that takes over VT 1, changes user to > > > 'vtty', and runs 'cage' which is a Wayland compositor, mostly > > > unprivileged. > > > > > > OR > > > > > > 1.b Have a system service, that takes over a seat directly, as the > > > kernel has the VT system disabled (or the seat is not seat0). > > > Changes user to 'vtty' and runs 'cage' mostly unprivileged. > > > > > > > > > 2. Inside cage, you run a Wayland terminal emulator as user 'vtty', > > >so mostly unprivileged. The terminal emulator creates a PTY. > > > > > > 3. Inside that terminal emulator, that is, connecting to that PTY, > > >you want to be able log in with any user. Therefore the program > > >running on the PTY should present a login prompt and succeed > > >in logging a user in and setting up his session, and switching > > >to a shell running as that user. > > > > > > All in all, this stack would replace the usual stack where > > > /bin/login runs directly on the TTY of a VT, allowing to use a more > > > featureful terminal, custom display modes, multi-output support, > > > maybe multiple parallel sessions for different users a la fast user > > > switching, and more. > > > > > > > Not to mention, getting Shift+PgUp back, (and now on multiseat systems, > > keyboard input from non-seat0 seats will no longer bleed into seat0 when VT > > 1-6 > > are active) :) > > > Am I guessing right? > > > > You are guessing correct. Thanks! > > > > > > Then the question is, how to organize all this so that it works, > > > and what program(s) should be used in step 3, and how? > > > > > > > > > My own proposal for this would be to run everything as systemd > > > system services: > > > > > > 1. Cage runs as a system service, as user 'vtty'. Cage will require > > >systemd integration so that it can tell systemd when it is ready > > >to accept Wayland clients. > > > > > > 2. The Wayland terminal runs as another systemd system service, > > >depending on the cage service, as user 'vtty'. > > > > > That's close to what I was trying, but cage is pretty cool in this regard, > > you > > can start > > cage -- vte > > and cage starts VTE as its only client, so the complexity of starting the > > wayland client externally, don't have to worry about that. > > But if cage starts the terminal, then systemd does not know when > the terminal is ready to accept a login program, or is there a way > to watch PTYs? > > Ideally the terminal too would integrate with systemd start-up > notification IPC. Perhaps let systemd control which PTY to use, so > the login program/service knows to connect to the right one. > > There's also auto-respawn, shutdown, cgroups, and more that systemd > can do. > > > > 3. The login program runs as a third systemd system service, > > >depending on the terminal service, as user 'root' because it > > >needs to be able log in a user and set up a session for them. > > > > > > That would solve the problem of how to get the necessary privileges > > > to log in a user, but all the other details I'm not sure. > > > > > That's what I was aiming to do, wasn't sure how to connect
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote: > On Fri, 21 May 2021 21:29:09 -0400 > nerdopolis wrote: > > > Sorry, I got the terminology mixed up again. I am still using TTYs to run > > the > > instances of `cage`. It's the kernel mode VT emulators I am replacing with > > the > > user mode terminal emulators (running under a fullscreen Wayland compositor) > > Hi, > > I'm trying to clarify things for everyone here, since I think I can > guess what you want to achieve, but you have a hard time explaining > your original goal. I hope you don't mind. > > That's fine. Thanks! > Starting from the outermost "layer" and going inwards: > > 1.a Have a system service, that takes over VT 1, changes user to > 'vtty', and runs 'cage' which is a Wayland compositor, mostly > unprivileged. > > OR > > 1.b Have a system service, that takes over a seat directly, as the > kernel has the VT system disabled (or the seat is not seat0). > Changes user to 'vtty' and runs 'cage' mostly unprivileged. > > > 2. Inside cage, you run a Wayland terminal emulator as user 'vtty', >so mostly unprivileged. The terminal emulator creates a PTY. > > 3. Inside that terminal emulator, that is, connecting to that PTY, >you want to be able log in with any user. Therefore the program >running on the PTY should present a login prompt and succeed >in logging a user in and setting up his session, and switching >to a shell running as that user. > > All in all, this stack would replace the usual stack where > /bin/login runs directly on the TTY of a VT, allowing to use a more > featureful terminal, custom display modes, multi-output support, > maybe multiple parallel sessions for different users a la fast user > switching, and more. > Not to mention, getting Shift+PgUp back, (and now on multiseat systems, keyboard input from non-seat0 seats will no longer bleed into seat0 when VT 1-6 are active) :) > Am I guessing right? You are guessing correct. Thanks! > > Then the question is, how to organize all this so that it works, > and what program(s) should be used in step 3, and how? > > > My own proposal for this would be to run everything as systemd > system services: > > 1. Cage runs as a system service, as user 'vtty'. Cage will require >systemd integration so that it can tell systemd when it is ready >to accept Wayland clients. > > 2. The Wayland terminal runs as another systemd system service, >depending on the cage service, as user 'vtty'. > That's close to what I was trying, but cage is pretty cool in this regard, you can start cage -- vte and cage starts VTE as its only client, so the complexity of starting the wayland client externally, don't have to worry about that. > 3. The login program runs as a third systemd system service, >depending on the terminal service, as user 'root' because it >needs to be able log in a user and set up a session for them. > > That would solve the problem of how to get the necessary privileges > to log in a user, but all the other details I'm not sure. > That's what I was aiming to do, wasn't sure how to connect to the service until I found I can do that with socat a few days after I sent that first email to the list, but I still feel I should still clarify here. and if you're really curious, I have the .service files I made public https://github.com/n3rdopolis/fakekmscon/tree/master/usr/lib/systemd/system > So the main idea here is to not run /bin/login *under* the terminal > emulator or cage, but as a system service which just connects to the > right PTY. I guess it would be like running /bin/login for a serial > terminal, it just connects to ttyS1 or whatever instead of tty1. > > Would that work? > > > Thanks, > pq ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Thursday, May 20, 2021 10:53:24 AM EDT wrote: > On So, 16.05.21 19:41, nerdopolis (bluescreen_avenger at verizon.net) wrote: > > > Hi > > > > I am trying to experiment around replacing the text mode TTYs with usermode > > utilities. > > I don't follow? > I am sorry, I will try to be more clear. That first email, went through several drafts, as at first it was longer and rambly, and I didn't want to bombard the list with a giant wall of text. (I actually found my solution was to use socat since sending that last email.) I was seeking some more existing programs I could try to cobble together to come up with a solution. The main things were: 1. /bin/login needs to be run as root for it to work 2. It's ill-advised to start a graphical terminal emulator as root - I looked into the existing kmscon, but it's older, and ran as root - I tried running tmux client/server with the server as root, the client as non-root. It worked in theory, but tmux didn't seem fit to run ONLY a login prompt - I tried using systemd-run, but it had the quirks I described BUT - I found I could do the same client-server thing with socat, not tmux. tmux has a basic way to forward a PTY to a socket, and then set the permissions on it for a non-root system user, and then connect to it from a command running under a terminal emulator running as that non-root user. So my solution ended up being something like: --- vtty-backend@tty1.service(u:root) vtty-frontend@tty1.service(u:vtty) socat exec:/bin/login unix-listen:/run/socketcage (wayland) /|\ vte (terminal emulator) | socat file:`tty` unix-connect:/run/socket<-| || --- That way there I was able to solve the first issue. (and actually the second issue too, by running the backend on a fake seat-vtty seat) > > While kmscon exists, the problem with it that I see is that it runs as root. > > It's most likely so it can run /bin/login as root, and /bin/login is not > > setuid > > > > > > I found that doing something like (Can't fit the command in 80 chars, > > sorry) > > systemd-run --setenv XDG_SEAT=$XDG_SEAT --setenv XDG_VTNR=$XDG_VTNR -t > > /bin/login -p > > can work in a way to run /bin/login within a non-privleged terminal > > emulator, > > however authentication is needed to run that command. > > hmm? XDG_VTNR is for the Linux VT subsystem but though i don't > understand what you are trying to do i get the impression you don't > want to use VTs? or do you? not following... > Sorry, I got the terminology mixed up again. I am still using TTYs to run the instances of `cage`. It's the kernel mode VT emulators I am replacing with the user mode terminal emulators (running under a fullscreen Wayland compositor) > > First question: > > Is there a supported way to allow a system user account to run one command > > without a password prompt with systemd-run? Otherwise I guess I can just > > make a > > setuid binary that calls the systemd-run command... > > It's PolicyKit enabled, you can allow your user to run unpriv > commands, but it's a all-or-nothing thing. > OK, that's kind of what I thought. Thanks for confirming. (If I hadn't found the other solution, I would have just made the setuid binary for kicking off systemd-run) > > The second thing: Things like nmtui need a full logind session to be able to > > run, and do polkit actions. However on seat0, it seems you need to decide > > on a > > empty TTY to use, which while you can use TTY63, that doesn't seem to be a > > 'clean' idea. > > Can't parse this, sorry. > I am sorry I was not clear, I'll try to use nmtui as an example to describe what I am seeing. nmtui is an example of a utility that needs polkit (or root) to work. It comes with NetworkManager. Start nmtui from a normal terminal emulator, or a classic tty, and you likely will be able to edit connections with it. Now if you do systemd-run -t /bin/login -p and then login, and run nmtui, that instance will then say "not authorized" I forgot what inspired me to experiment with setting XDG_SEAT but if you systemd-run -t --setenv=XDG_SEAT=seat0 /bin/login -p and then log in, and nmtui still doesn't work. Check the journal, you will get an error "failed to create session: VT number out of range" where the VT number th
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Sunday, May 16, 2021 7:41:30 PM EDT wrote: > Hi > > I am trying to experiment around replacing the text mode TTYs with usermode > utilities. > > > While kmscon exists, the problem with it that I see is that it runs as root. > It's most likely so it can run /bin/login as root, and /bin/login is not > setuid > > > I found that doing something like (Can't fit the command in 80 chars, > sorry) > systemd-run --setenv XDG_SEAT=$XDG_SEAT --setenv XDG_VTNR=$XDG_VTNR -t > /bin/login -p > can work in a way to run /bin/login within a non-privleged terminal emulator, > however authentication is needed to run that command. > > (there also seems to be no way to turn off the "press ^] to disconnect" > option) > > > > First question: > Is there a supported way to allow a system user account to run one command > without a password prompt with systemd-run? Otherwise I guess I can just make > a > setuid binary that calls the systemd-run command... > > > > > The second thing: Things like nmtui need a full logind session to be able to > run, and do polkit actions. However on seat0, it seems you need to decide on a > empty TTY to use, which while you can use TTY63, that doesn't seem to be a > 'clean' idea. > > > > One interesting workaround that DOES work is loading the vkms driver, adding > the virtual card to a seat called 'seat-vtty' and then starting the login > process on the virtual seat. That allows a full logind session to run and > things like nmtui actually work > modprobe vkms > loginctl attach seat-vtty /sys/devices/platform/vkms/drm/card1 > systemd-run --setenv XDG_SEAT=seat-vtty -t /bin/login -p > > > The fake video card device being added forces logind to create the seat-vtty > seat. From that login prompt, I can log in and have polkit work, testing with > nmtui. It's a bit odd having to use a virtual hardware device to make a fake > seat, but it works to get around the TTY restriction for seat0... > > Thanks > > > Hi I think I came up with a solution for myself for Question 1. I will have one service start /bin/login in a PTY with socat, to a socket file with the permissions set for the service user, and then socat running under a terminal emulator that runs as the service user will connect. I actually already had some nice co-dependent .service files already, when I first tried a socket based solution with tmux. But tmux was hard to nerf to be "kiosk quality" to act similar to a login TTY. socat seems like it might be a better fit, so I think I can call off having to worry about calling systemd-run with a setuid binary, or making a complex polkit rule, or tweaking systemd-run to disable the ^] disconnect ability... Question 2, yeah it seems that manager_process_seat_device() is the only thing that ends up calling seat_new() after some grepping, but I did find that if I set master-of-seat as a property a device, and add it with udev, I don't have to use the vkms driver, instead I can say use /dev/tty or something, which is at least cleaner than using a virtual display device Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
Hi I am trying to experiment around replacing the text mode TTYs with usermode utilities. While kmscon exists, the problem with it that I see is that it runs as root. It's most likely so it can run /bin/login as root, and /bin/login is not setuid I found that doing something like (Can't fit the command in 80 chars, sorry) systemd-run --setenv XDG_SEAT=$XDG_SEAT --setenv XDG_VTNR=$XDG_VTNR -t /bin/login -p can work in a way to run /bin/login within a non-privleged terminal emulator, however authentication is needed to run that command. (there also seems to be no way to turn off the "press ^] to disconnect" option) First question: Is there a supported way to allow a system user account to run one command without a password prompt with systemd-run? Otherwise I guess I can just make a setuid binary that calls the systemd-run command... The second thing: Things like nmtui need a full logind session to be able to run, and do polkit actions. However on seat0, it seems you need to decide on a empty TTY to use, which while you can use TTY63, that doesn't seem to be a 'clean' idea. One interesting workaround that DOES work is loading the vkms driver, adding the virtual card to a seat called 'seat-vtty' and then starting the login process on the virtual seat. That allows a full logind session to run and things like nmtui actually work modprobe vkms loginctl attach seat-vtty /sys/devices/platform/vkms/drm/card1 systemd-run --setenv XDG_SEAT=seat-vtty -t /bin/login -p The fake video card device being added forces logind to create the seat-vtty seat. From that login prompt, I can log in and have polkit work, testing with nmtui. It's a bit odd having to use a virtual hardware device to make a fake seat, but it works to get around the TTY restriction for seat0... Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Possible support for child logind sessions running under a display server?
Hi I have been experimenting with cobbling up some sort of non-root kmscon alternate by combining wlroots based cage and vte, However Two problems force me to run it as root. (The first being the obvious escalation of /bin/login which might be possible to do with systemd-run and pkexec and a custom policy) The second being that for polkit to work in the session XDG_SEAT and XDG_VTNR both need to be set. However if an existing session is using that XDG_VTNR the polkit session fails to start For example, under a terminal running under a graphical session run: system-run --setenv=XDG_SEAT=$XDG_SEAT --setenv=XDG_VTNR=$XDG_VTNR -t -- login -p then logging in with the prompt, and then trying `pkexec ls` access is denied, because I guess that XDG_VTNR is already used. adding --setenv=XDG_VTNR=63 to `systemd-run` works, but not feasible as it doesn't work quite right So could something like where if XDG_SESSION_CLASS="guest" the session won't need a VTNr on seat0 be acceptable? Although I guess these child sessions in theory, they won't be activateable, as the session for the host display server will need to be active for the host display server to actually work... 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 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
[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
Re: [systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0
On Wednesday, April 8, 2020 3:35:08 AM EDT Pekka Paalanen wrote: > On Tue, 07 Apr 2020 23:03:52 -0400 > nerdopolis wrote: > > > On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote: > > > On Thu, 02 Apr 2020 22:59:25 -0400 > > > nerdopolis wrote: > > > > > ... > > > > > One thing I did notice though is that (as far as leaking input) > > > > > > > > - if run Display Servers on the secondary seat (one, or more than one) > > > > - On seat0, I chvt to a text-mode TTY > > > > - Continuing to use the secondary seat, all keyboard and mouse (gpm) > > > > input > > > > gets sent to the TTY (and the actual display server) > > > > - Switching back to a TTY with a display server, and the seats behave > > > > separate > > > > again > > > > > > > > > > > > My (maybe bad) guess is that it would need to be addressed in the > > > > kernel though > > > > And the CanMultiSession attribute on non-seat0 doesn't matter when the > > > > problem > > > > is all input from all devices gets sent to seat0 when seat0 is in a > > > > text mode > > > > TTY > > > > > > > > ..and even if you have some kmscon like thing installed, there could > > > > still be > > > > text mode TTYs > > > > > > Hi, > > > > > > that is both an excellent and horrifying observation. And it makes > > > perfect sense to me why that happens, just like you think: seat > > > assignments happen in userspace as udev properties. Someone would have > > > to explicitly tell the kernel about it too to fix this, e.g. remove > > > non-seat0 devices from the VT machinery. > > > > > > I wonder if such kernel interface even exists? > > > > > > The reason why display servers do not cross their input streams like > > > that is that display servers do not use the VT for input. But VT gets > > > its input assigned directly inside the kernel. > > > > > > > > > Thanks, > > > pq > > Hi > > > > I'm not sure, but I am not an expert there. haha. However, I am just > > remembering as far as gpm goes,that one runs in userspace, as root so it's > > also not obeying seats, but THAT part is not the fault of the kernel. > > Yeah, a program running as root can do whatever it chooses to. So that > part is a GPM bug or lack of configuration, I don't know which. > yeah gpm appears to be old. some of the files not modified in 12 years, which is older than logind I think. So forget I said anything about gpm. Sorry about that. > > Maybe a utility could be made like gpm that grabs the keyboard input, but > > only > > forwards the keys to the TTY, if the device is in seat0. But like, I am > > guessing here, and I guess it would be a possibility for the hypothetical > > utility to crash, and then all input would get sent to the TTY anyway. > > That would seem like strange architecture as the VT is implemented in > the kernel, but you would route the input events through userspace. > > Instead of that, I'd promote CONFIG_VT=n and run something like kmscon > to replace the VTs. I expect that to need effort to make work though, > since I haven't heard anything from that direction in years. That is, > disable the kernel VT sub-system completely, and use userspace programs > to offer similar functionality while leveraging logind and other modern > technologies. > > But if people want to keep CONFIG_VT=y, then I don't see any other way > than telling the kernel which input devices belong with the VT and > which do not. Perhaps logind should do that. > yeah, that is probably a ways out maybe, and systems that have an older card that doesn't support mode-setting or a framebuffer will probably not have a way to display a console without CONFIG_VT, right? Unless a generic KMS VESA driver exists or something. Maybe udev could set some new sysfs attribute on devices or something if they are in seat0 or not. But I don't know how the vt subsystem works, if it can even exclude a particular keyboard like that or not. > > So I'm not sure, also should we change the name of the thread since I think > > my > > original question is answered now? > > Done. I hope this attracts more attention. > Thanks. > > Thanks, > pq ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote: > On Thu, 02 Apr 2020 22:59:25 -0400 > nerdopolis wrote: > > > On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote: > > > On Di, 28.01.20 22:48, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > > > > > Hi > > > > > > > > Sorry if this is the wrong place for this. I can't seem to find a > > > > system-user > > > > mailing list for this purpose on freedesktop. > > > > > > > > So I am curious about what CanMultiSession=no means, as I am able to > > > > start a > > > > Weston session on a secondary seat (eg seat1 if I set up the hardware > > > > with udev > > > > or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU. > > > > > > > > These seats, since they don't have TTYs I guess say CanMultiSession=no > > > > which is > > > > my understanding, however, I can start a second instance of Weston, and > > > > switch > > > > in between them fine, and Weston seems to respond to the sessions > > > > switching, so > > > > I am not quite sure what is missing? Is it something else related to > > > > security? > > > > Or the kernel? > > > > > > > > Because as far as I can tell, I can start multiple sessions on these > > > > seats. > > > > > > Hmm, so it currently just lets you know if the seat has VTs (which > > > only seat0 has effectively, if the VT subsys is enabled in the > > > kernel). > > > > > > In the old days we only supported session switching on seat0, since it > > > was based exclusively on VTs. Later on David Hermann added support for > > > session switching without VTs, at which point the boolean was wired to > > > mean "has VTs". Maybe that was a mistake, dunno, and it should just > > > have returned true for all seats at that point... > > > > > > Lennart > > > > > > -- > > > Lennart Poettering, Berlin > > > > > Thanks. I was wondering if there was some security thing that depended on > > TTYs > > for the two Display Servers running on the same seat to truly be secure or > > not. > > (like reading /dev/input/* ) > > > > If you don't need TTYs to prevent the non-seat0 session from reading input > > from > > the other non-seat0 session, the same as on seat0, then yeah, as I've been > > able > > to run and switch between two sessions on non-seat0 since I first tried it > > in > > 2017... > > > > > > > > One thing I did notice though is that (as far as leaking input) > > > > - if run Display Servers on the secondary seat (one, or more than one) > > - On seat0, I chvt to a text-mode TTY > > - Continuing to use the secondary seat, all keyboard and mouse (gpm) input > > gets sent to the TTY (and the actual display server) > > - Switching back to a TTY with a display server, and the seats behave > > separate > > again > > > > > > My (maybe bad) guess is that it would need to be addressed in the kernel > > though > > And the CanMultiSession attribute on non-seat0 doesn't matter when the > > problem > > is all input from all devices gets sent to seat0 when seat0 is in a text > > mode > > TTY > > > > ..and even if you have some kmscon like thing installed, there could still > > be > > text mode TTYs > > Hi, > > that is both an excellent and horrifying observation. And it makes > perfect sense to me why that happens, just like you think: seat > assignments happen in userspace as udev properties. Someone would have > to explicitly tell the kernel about it too to fix this, e.g. remove > non-seat0 devices from the VT machinery. > > I wonder if such kernel interface even exists? > > The reason why display servers do not cross their input streams like > that is that display servers do not use the VT for input. But VT gets > its input assigned directly inside the kernel. > > > Thanks, > pq Hi I'm not sure, but I am not an expert there. haha. However, I am just remembering as far as gpm goes,that one runs in userspace, as root so it's also not obeying seats, but THAT part is not the fault of the kernel. Maybe a utility could be made like gpm that grabs the keyboard input, but only forwards the keys to the TTY, if the device is in seat0. But like, I am guessing here, and I guess it would be a possibility for the hypothetical utility to crash, and then all input would get sent to the TTY anyway. So I'm not sure, also should we change the name of the thread since I think my original question is answered now? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote: > On Di, 28.01.20 22:48, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > Hi > > > > Sorry if this is the wrong place for this. I can't seem to find a > > system-user > > mailing list for this purpose on freedesktop. > > > > So I am curious about what CanMultiSession=no means, as I am able to start a > > Weston session on a secondary seat (eg seat1 if I set up the hardware with > > udev > > or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU. > > > > These seats, since they don't have TTYs I guess say CanMultiSession=no > > which is > > my understanding, however, I can start a second instance of Weston, and > > switch > > in between them fine, and Weston seems to respond to the sessions > > switching, so > > I am not quite sure what is missing? Is it something else related to > > security? > > Or the kernel? > > > > Because as far as I can tell, I can start multiple sessions on these seats. > > Hmm, so it currently just lets you know if the seat has VTs (which > only seat0 has effectively, if the VT subsys is enabled in the > kernel). > > In the old days we only supported session switching on seat0, since it > was based exclusively on VTs. Later on David Hermann added support for > session switching without VTs, at which point the boolean was wired to > mean "has VTs". Maybe that was a mistake, dunno, and it should just > have returned true for all seats at that point... > > Lennart > > -- > Lennart Poettering, Berlin > Thanks. I was wondering if there was some security thing that depended on TTYs for the two Display Servers running on the same seat to truly be secure or not. (like reading /dev/input/* ) If you don't need TTYs to prevent the non-seat0 session from reading input from the other non-seat0 session, the same as on seat0, then yeah, as I've been able to run and switch between two sessions on non-seat0 since I first tried it in 2017... One thing I did notice though is that (as far as leaking input) - if run Display Servers on the secondary seat (one, or more than one) - On seat0, I chvt to a text-mode TTY - Continuing to use the secondary seat, all keyboard and mouse (gpm) input gets sent to the TTY (and the actual display server) - Switching back to a TTY with a display server, and the seats behave separate again My (maybe bad) guess is that it would need to be addressed in the kernel though And the CanMultiSession attribute on non-seat0 doesn't matter when the problem is all input from all devices gets sent to seat0 when seat0 is in a text mode TTY ..and even if you have some kmscon like thing installed, there could still be text mode TTYs but that is not relevant as far as CanMultiSession is concerned... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] The meaning of CanMultiSession=no on non-seat0
Hi Sorry if this is the wrong place for this. I can't seem to find a system-user mailing list for this purpose on freedesktop. So I am curious about what CanMultiSession=no means, as I am able to start a Weston session on a secondary seat (eg seat1 if I set up the hardware with udev or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU. These seats, since they don't have TTYs I guess say CanMultiSession=no which is my understanding, however, I can start a second instance of Weston, and switch in between them fine, and Weston seems to respond to the sessions switching, so I am not quite sure what is missing? Is it something else related to security? Or the kernel? Because as far as I can tell, I can start multiple sessions on these seats. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two questions about logind and seats
On Wednesday, August 2, 2017 3:17:37 AM EDT Lennart Poettering wrote: > On Di, 01.08.17 19:32, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > On Tuesday, August 1, 2017 3:00:25 AM EDT Lennart Poettering wrote: > > > On Mo, 31.07.17 21:24, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > > > > > > > First, when I attach a 2nd graphics card to seat1, it seems > > > > > > CanMultisession is > > > > > > set to 0. Is there a way to change that? or is that only supported > > > > > > on seat0, > > > > > > that supports the TTYs? > > > > > > > > > > Yes, this is only supported where VTs are supported, and that is > > > > > only seat0. > > > > > > > > Thanks, It's currently a kernel limitation I assume? I guess I'll worry > > > > about > > > > multiple sessions on non seat0 seats when it _is_ supported. > > > > > > Yeah the VCs are drawn by the kernel, hence doing multi-session on > > > other but the first seat would mean either updating the kernel or > > > doing something purely in userspace with a userspace terminal > > > renderer. David Hermann was working on something like this, but he > > > lost interest. > > > > > > Lennart > > > > > > > > Out of curiosity, what would the likes of Weston, X, and other Display > > Servers > > need on seats outside of seat0? A device to set KD_GRAPHICS on, like a > > special > > type of pty or something? > > Nah. Graphical display managers just need a set of DRM and input > devices to operate on, they require no VTs, ttys, ptys or anything. > > Lennart > > Thanks, I was wondering what would be needed from the kernel, and/or user space to be able to run two Display Servers on seat1/seat-1, and switch between them though? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two questions about logind and seats
On Tuesday, August 1, 2017 3:00:25 AM EDT Lennart Poettering wrote: > On Mo, 31.07.17 21:24, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > > > First, when I attach a 2nd graphics card to seat1, it seems > > > > CanMultisession is > > > > set to 0. Is there a way to change that? or is that only supported on > > > > seat0, > > > > that supports the TTYs? > > > > > > Yes, this is only supported where VTs are supported, and that is > > > only seat0. > > > > Thanks, It's currently a kernel limitation I assume? I guess I'll worry > > about > > multiple sessions on non seat0 seats when it _is_ supported. > > Yeah the VCs are drawn by the kernel, hence doing multi-session on > other but the first seat would mean either updating the kernel or > doing something purely in userspace with a userspace terminal > renderer. David Hermann was working on something like this, but he > lost interest. > > Lennart > > Out of curiosity, what would the likes of Weston, X, and other Display Servers need on seats outside of seat0? A device to set KD_GRAPHICS on, like a special type of pty or something? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two questions about logind and seats
On Monday, July 31, 2017 9:41:46 AM EDT Lennart Poettering wrote: > On Sa, 29.07.17 00:34, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > Hi > > > > I hope this is the right place to ask this. I have two questions about > > logind > > and seats. > > > > First, when I attach a 2nd graphics card to seat1, it seems CanMultisession > > is > > set to 0. Is there a way to change that? or is that only supported on > > seat0, > > that supports the TTYs? > > Yes, this is only supported where VTs are supported, and that is only seat0. Thanks, It's currently a kernel limitation I assume? I guess I'll worry about multiple sessions on non seat0 seats when it _is_ supported. > > > Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if > > that > > is required), is there a way to spawn a process on seat1 if it exits? > > For seat0 sessions, they for instance can be started by specifying > > > -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty > > --pStandardInput=tty > > Other seats don't have VTs, hence you cannot run anything on any such > VTs... Thanks, I will try to figure out how to get around Weston looking for a TTY when being run on not-seat0. > > To make use of these other seats you need some kind of terminal > emulator that knows how to draw to DRM directly, and then you can > connect your service to that. > > > to systemd-run, which I know only seat0 supports ttys... > > I try to do weston --seat=seat1 and it says that seat1 does not match the > > session-seat. > > Is there a way to start a process with under a specific session-seat? > > Well, I don't know weston that well, but presumably you are invoking > it from a session that is attached to seat0, and it doesn't like that > you try to run it on a different seat then, which makes a ton of sense > to complain about. Contact the weston folks for help on this. > Thanks I figured this one out, I didn't know I could change the session-seat by exporting XDG_SEAT before calling systemd-run, I wasn't aware that pam-systemd.so would _read_ the variable too. > Lennart > > Thanks for the assistance! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two questions about logind and seats
Hi It seems I answered my first question seems setting --setenv=XDG_SEAT=seatx and that will cause pam_systemd.so to set the session-seat to what the variable is set to. While the documentation says that pam_systemd.so can _set_ to the variables, it wasn't clear that it also _responds_ to what they are set to. I still have my other question, is it possible to set CanMultisession to yes on other seats besides seat0? Thanks On Saturday, July 29, 2017 12:34:46 AM EDT nerdopolis wrote: > Hi > > I hope this is the right place to ask this. I have two questions about logind > and seats. > > First, when I attach a 2nd graphics card to seat1, it seems CanMultisession is > set to 0. Is there a way to change that? or is that only supported on seat0, > that supports the TTYs? > > Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if that > is required), is there a way to spawn a process on seat1 if it exits? > For seat0 sessions, they for instance can be started by specifying > > > -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty > -pStandardInput=tty > > > to systemd-run, which I know only seat0 supports ttys... > I try to do weston --seat=seat1 and it says that seat1 does not match the > session-seat. > Is there a way to start a process with under a specific session-seat? > > > > Thanks > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Two questions about logind and seats
Hi I hope this is the right place to ask this. I have two questions about logind and seats. First, when I attach a 2nd graphics card to seat1, it seems CanMultisession is set to 0. Is there a way to change that? or is that only supported on seat0, that supports the TTYs? Second, with systemd-run, and maybe a custom '-p PAMName=somepamfile' (if that is required), is there a way to spawn a process on seat1 if it exits? For seat0 sessions, they for instance can be started by specifying -pTTYPath=/dev/ttyX -pStandardOutput=tty -pStandardError=tty -pStandardInput=tty to systemd-run, which I know only seat0 supports ttys... I try to do weston --seat=seat1 and it says that seat1 does not match the session-seat. Is there a way to start a process with under a specific session-seat? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dbus: fix --system handling
On Monday, October 25, 2010 08:40:50 PM Lennart Poettering wrote: > On Tue, 26.10.10 00:44, Michael Biebl (mbiebl at gmail.com) wrote: > > 2010/10/26 Lennart Poettering : > > > Note that we do not support booting a real system with systemd on PID > > > != 1. The primary reason for that is that we need the SIGCHLD signals > > > properly, and we only get those as PID 1. Early systemd versions > > > supported a mode where we didn't rely on those signals. However, we > > > removed that after a while, since I didn't see much benefit in this > > > mode and I was unable and unwilling to keep this mode working and do > > > the necessary testing. > > > > This leads to an interesting question: How do you intend to support > > running services within a chroot? > > What is your plan for this case? > > Hmm, can upstart/sysvinit be run in a chroot env? > > I don't think chroot should be taken for a container solution. Because > it's not. If you want a container, use a container, i.e. something > cgroups based such as lxc or so. While I haven't tested that I think it > should mostly work including stuff like like proper SIGCHLD handling. If > things don't fully work, then this is definitely something to fix, in > contrast to weird systemd-in-a-chroot behaviour I think. > > I think chroot can be a useful tool for jailing particular services into > subtrees of the fs hierarchy. Either in the way that the service itself > internally chroot()s (which Avahi does, as I think the only service > [still!] which does that by default). Or in a way that this is done > externally, for example via RootDirectory= in systemd service > files. However, I think that the babysitter in that case should live > outside of the jail. > > So I think we are well covered here. Or am I missing something? > > Lennart Hi. so will it be possible to run a seperate systemd outside of a chroot for a chroot? ( bonus if not as PID 1) My concern is that currently with Upstart, (I don't know about other package managers) and dpkg in a chroot, some packages will install, and then try to start its service automatially (by connecting to Upstart). Since it can't connect, the package reports failure to install, and dpkg stops dead in its tracks, and it won't continue. I tried chrooting into a system that uses systemd, and starting a systemd service and noticed that it reports it can't connect. If a package attempted to start a service like that in chroot, it probably would fail. This mostly will affect people trying to install some packages on an offline system. Are my arguments valid? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
