On Monday 18 August 2014 18:22:42 Martin Gräßlin wrote: > On Monday 18 August 2014 17:48:03 Pier Luigi wrote: > > 2014-08-15 7:35 GMT+02:00 Martin Gräßlin <mgraess...@kde.org>: > > > * concerning the lock/unlock: I would like to have the lock way better > > > integrated in KWin. That is KWin should be responsible for locking and > > > nobody else. My though is that KWin takes over the screen locker dbus > > > interface and starts the screenlocker greeter when it's needed. It > > > could > > > pass a dedicated fd to greeter and thus would know that it's the lock > > > screen surface implicitly. That way we would not need a protocol at all > > > and it's completely controlled by KWin. > > > > How do you know its wl_surface? > > > > Would be better to move lock/unlock to a separate .xml file and have > > ksmserver handle that imho. > > kwin or any other compositor would recognize the surface by its role then. > > I had thought about it over the weekend how it could work: > *) ksld gets split into an own library > *) kwin uses this ksld library > *) ksld gets extended so that we can provide additional arguments to be > passed to the greeter > *) we pass the fd or socket name to the greeter > *) any wl_surface coming over this fd with the greeter's pid is a lock > screen surface > (maybe only providing the fullscreen protocol for this socket)
Feel like you are reinventing libwayland here. > What's important to me is to have the lock screen absolutely secure and that > includes that in KWin I do not want to trust any other process and > especially want to have the basics around screen locking inside KWin and > being controlled by KWin. As soon as the screen is supposed to be locked, > the input processing must stop, no matter whether the greeter is ready or > not. If we leave it in ksmserver there will always be a timing vector and > also the problem of knowing when to unlock - attacking the greeter should > not result in chances to unlock the screen. The lock/unlock protocols serves exactly this purpose, here's a verbose description of how it works: *) ksmserver is a Wayland client that binds kf5_shell *) ksmserver is asked to lock (via loginctl, plasmoid or context menu) *) ksmserver calls the kf5_shell.lock request *) kwin hides all surfaces, prevent input and maybe turn the screen off, this is all independent from the greeter being running or not *) kwin emits the prepare_lock_surfaces and ksmserver picks it up *) ksmserver runs the greeter which will create the surfaces *) ksld use set_surface_role to set the lock role on those surfaces *) kwin set lock surfaces position on its layer *) Keyboard, touch or mouse input happens and the screen is turned on *) User authenticates and ksld calls unlock *) kwin resumes the desktop and ksld destroys the surfaces Note that lock/unlock requests can be moved to a dedicated interface. > > > * add_trusted_client: I kind of don't understand how that's supposed to > > > work. Where's the fd coming from and how does the shell user know about > > > it? > > > > It's the fd of a socket to the Wayland server open by the client that > > need to be trusted. > > > > This comes from Weston having the screenshooter interface and a screenshot > > tool. The idea was to forbid clients not in the whitelist to use that > > interface and thus avoid malicious programs to capture your screen. > > A shell would open the screenshooter program when it needs to do a > > screenshot and add it to the whitelist. > > > > This can probably go away although I don't know how ksnapshot will > > work on Wayland. > > ah well - I know there was a discussion about handling such clients. Not to > myself: read those mails ;-) In general I'm not a fan of whitelists as that > makes everything just more complex - we allow ksnapshot, but what about > krita? Krita should ask the shell to make a screenshot, the shell then executes a trusted program. Now I wonder what makes ksnapshot so special, the path? It's better if we wait until the Wayland people come up with a better mechanism. > My suggestion would be to keep that as a questionmark till the XDC where I > could get some briefing by the people working on it ;-) OK mean time I commented the request. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
