Hi, On Fri, Apr 17, 2020 at 9:58 AM Benjamin Berg <benja...@sipsolutions.net> wrote: > I do however think there is value in supporting such delegation from > the logind side. A primary motivator for me here is systemd-homed, as > it may freeze the user session, making it impossible to re-authenticate > from within. So my plan for systemd-homed was going to be to just make the GDM session worker jump to VT1. Today, if we jump to VT1 a login screen will materialize and all should just work.
We could add some mechanism to logind to register where a login screen will go and provide a way for logind to jump to that login screen instead, sure. > And really, it would be better if we don't let the user ever see their own > password. not sure what you mean by this. are you talking about ensuring trusted path? If so, I agree it's better if we don't have the user entering their password in their own session. In an ideal world we'd have a "secure attention" key or key sequence on the keyboard that users hit when it's time to type their password. > But, it should be as simple as logind forcing a VT switch to the > correct greeter UI/session. Plus a little bit more magic to maybe spin > up the UI in the background before suspending and pre-selecting the > user to make the experience smoother. Right, I'm definitely not opposed to api getting added to logind for this, but I also don't think it's strictly necessary. We can do it all from GDM pretty easily. Probably when I play with systemd-homed I'll prototype things out on the GDM side first. But, I also think this is an orthogonal discussion to remote desktop support. (maybe one better for the systemd list?) --Ray _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
