Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze: > On Thu, 9 Apr 2020 09:46:08 +0200 > Lennart Poettering wrote: > >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: >> 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? >> >> There are ioctls for that in the input layer if iirc, but i don't >> remember how precisely this works. You are hacking on a compositor, you >> should know ;-) > > Hi, > > while hacking on a compositor, I have never needed to stop specific > input devices from being routed to the VT system while allowing others. > If a compositor runs on seat0, it will disable the whole VT input side > (among other things) with one VT ioctl IIRC. In this case that is not > wanted, because seat0 is intended to be used with the VT text mode and > VT input, so disabling all VT input would stop also the wanted input. Not sure if it's related and I don't know details, but some software like brltty or a fenrir console screenreader are routinely taking control over single input devices in text mode. The whole point is that they take control over all real keyboards, and have some uinput device that is still wired to vt, so that I can send keypresses not supported by terminals like insert+something, and these that do not map to screenreader would be injected to the uinput and appear on vt. I thought display servers also take exclusive control over specific input devices... hmm. If they do then this behavior should likely not be happening as they still are in control of the devices. > > Also a display server that runs on non-seat0 seat should never touch > anything about VTs AFAIU. I would expect it to not have the permissions > to do that even if it wanted to. > > Like you said it being a kernel or logind bug, this is something that > needs to be taken care of below the compositor, automatically keyed by > the input device seat assignments. > > > Thanks, > pq > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > signature.asc Description: OpenPGP digital signature ___ 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 Thu, 9 Apr 2020 09:46:08 +0200 Lennart Poettering wrote: > On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > > > 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? > > There are ioctls for that in the input layer if iirc, but i don't > remember how precisely this works. You are hacking on a compositor, you > should know ;-) Hi, while hacking on a compositor, I have never needed to stop specific input devices from being routed to the VT system while allowing others. If a compositor runs on seat0, it will disable the whole VT input side (among other things) with one VT ioctl IIRC. In this case that is not wanted, because seat0 is intended to be used with the VT text mode and VT input, so disabling all VT input would stop also the wanted input. Also a display server that runs on non-seat0 seat should never touch anything about VTs AFAIU. I would expect it to not have the permissions to do that even if it wanted to. Like you said it being a kernel or logind bug, this is something that needs to be taken care of below the compositor, automatically keyed by the input device seat assignments. Thanks, pq pgpuxzIOa4N0o.pgp Description: OpenPGP digital signature ___ 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 Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > 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? There are ioctls for that in the input layer if iirc, but i don't remember how precisely this works. You are hacking on a compositor, you should know ;-) Lennart -- Lennart Poettering, Berlin ___ 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 Do, 02.04.20 22:59, nerdopolis (bluescreen_aven...@verizon.net) wrote: > 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/* ) The input subsystem has ioctls we use to switch access. THis should be reasonably secure. DRM the same. > 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... keypresses these days are read via the input subsystems, ttys are only used for classic text logins at this point. > 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 hmm, this smells like a bug, either in logind or in the kernel. can you file an issue about this? Lennart -- Lennart Poettering, Berlin ___ 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 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 pgpmubB9uXJ6V.pgp Description: OpenPGP digital signature ___ 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
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
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 ___ 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
