> On Okt. 14, 2014, 7:02 vorm., Martin Klapetek wrote: > > Could we possibly get "Suspend" button instead? Suspend stores the session > > state into memory and then restores it without any issues (and we lock > > screen on wakeup anyway); many times I have found my laptop with locked > > screen and I had to unlock, click the suspend button in the panel only to > > get it locked again and suspended. > > Martin Gräßlin wrote: > I expected this question to come :-) - I'm not sure whether it's a valid > use case, at least for laptops. Closing the lid should send it to suspend, > the suspend button should still work (if not, we should fix it). So there are > already quite some decent ways to get the system to suspend when locked. > Especially with lid closing it does what it's supposed to do. > > In fact the functionality should even be available through the Change > Session functionality as that drops you to the login manager where you can > suspend. Sure not as comfortable as directly exposing it. But we don't need > to expose every option which might make sense ;-) > > Kai Uwe Broulik wrote: > Although closing the lid apparently reliably suspends the device, even > when locked, my gut makes me not trust it. :/ > > Martin Gräßlin wrote: > > Although closing the lid apparently reliably suspends the device, even > when locked, my gut makes me not trust it. :/ > > At least my notebook(s) have a visible LED indicating it is in sleep mode. > > Martin Klapetek wrote: > There are still usecases however where either the user does not want/need > to close the lid and/or sets his laptop to not suspend on the lid close > (personally I have that disabled when on charger). Plus there is the whole > non-laptop world. It's not about exposing every option that makes sense, it's > about replacing one senseless with one that makes more sense ;) > > Martin Gräßlin wrote: > > It's not about exposing every option that makes sense, it's about > replacing one senseless with one that makes more sense ;) > > I don't see it that way. The option got added in a strange way shortly > before the 5.0 release with the maintainers of the screenlocker not having a > chance to review it (let's say it simple: if I would have reviewed the code, > it would not have gone in, in the first place). So I'm comparing to the last > state where it was working which is 4.11 and there the screen locker did not > expose such an option and I want to go back to that working state. Let's look > from there whether it's a valid option to expose the suspend option and not > from the broken state. > > To me it's not a valid use case to expose suspend in the lock screen. To > a certain degree it circumvents security. Suspend/Hibernate is allowed on a > per-user logged in base. That's implemented by checking whether > suspend/hibernate is supported at runtime. By exposing it in the screenlocker > it circumvents the check. A not logged in user (or a user who is not allowed > to supsend in his session) is able to suspend (multi user system just needs > to switch to a logged session which allows suspend). Thus I think from a > security perspective the option may not be there in the first place. > > Martin Klapetek wrote: > Oh come on, that's hardly any security circumvention. By that logic we > should not show battery state, current user's date/time, user name and user > picture in the lock screen either because it's exposing things which other > users might have restricted access to. > > Plus you said in the very first comment that it's possible to go around > this to the login screen and from there anyone can suspend... > > Martin Gräßlin wrote: > > Plus you said in the very first comment that it's possible to go around > this to the login screen and from there anyone can suspend... > > yes and no. In a multi-user system you can of course configure the system > in a way to not allow suspend/hibernate from login manager. > > It all boils down to: why do we go all the hassle to check whether this > options should be enabled from a security point of view, when we allow it for > not logged-in users. If we go for allow for not logged in users, we can > remove quite a decent amount of code... > > Kai Uwe Broulik wrote: > Having a suspend button is a security issue but closing the lid, which > causes it to suspend, is not? > > Martin Gräßlin wrote: > > Having a suspend button is a security issue but closing the lid, which > causes it to suspend, is not? > > no, as that is controlled by logind. If the system is configured to not > allow it, logind won't suspend the system if the lid closes.
So, the button should also honor that policy? - Kai Uwe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 ----------------------------------------------------------- On Okt. 14, 2014, 5:41 vorm., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > ----------------------------------------------------------- > > (Updated Okt. 14, 2014, 5:41 vorm.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Repository: plasma-workspace > > > Description > ------- > > Logging out from the locked screen is impossible. Logging out means > interaction with the session due to the session manager. The session > manager asks all applications to quit and applications are allowed to > ask for example saving changes. The session manager stopps the > logout in this case and asks the window manager to focus this window > and the session manager will only continue the logout once the > application resolved the situation. At any time in this process the > user is still able to abort the logout! > > Switching to the application which needs interaction is impossible, > though as the screen is still locked. The result is a seemingly > frozen system as the logout cannot continue and there is no indication > what is going on. > > Of course the lock screen cannot unlock the session for the logout as > that would circumvent the security. If the lock screen would unlock > one would just have to click the button and abort the logout really > fast to have the system unlocked. So this is clearly not an option. > > The result is: we cannot implement this functionality in a working > and secure manner, so it's better to remove it. > > > Diffs > ----- > > lookandfeel/contents/lockscreen/LockScreen.qml > 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d > > Diff: https://git.reviewboard.kde.org/r/120577/diff/ > > > Testing > ------- > > run kscreenlocker_greeter --testing and locked the screen - button is gone. > > > Thanks, > > Martin Gräßlin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
