Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/ --- 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- 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 Klapetek On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. 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 ;-) - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> 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 ;-) Although closing the lid apparently reliably suspends the device, even when locked, my gut makes me not trust it. :/ - 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. :/ > 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 --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. 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 --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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 ;) > 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 --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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 functional
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. 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 --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > 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 th
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68352 --- +1000 from me - Marco Martin On Ott. 14, 2014, 5:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Ott. 14, 2014, 5:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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... > 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... - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Repository: plasma-workspace > > > Description > --- > > Logging out from
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> 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... Having a suspend button is a security issue but closing the lid, which causes it to suspend, is not? - 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 Ok
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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? > 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. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 --- On Oct. 14, 2014, 7:41 a.m
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> 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/#revie
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > So, the button should also honor that policy? The thing is (I think) that having the button exposed for user A would allow user B to suspend the
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Říj. 14, 2014, 9:02 dop., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68365 --- This is related to https://bugs.kde.org/show_bug.cgi?id=339453 for the record - Eike Hein On Oct. 14, 2014, 5:41 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 5:41 a.m.) > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/ --- (Updated Oct. 14, 2014, 9:45 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Changes --- Add bug no Bugs: 339453 https://bugs.kde.org/show_bug.cgi?id=339453 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68374 --- I think it's unfortunate, you're giving a mix of technical and usability reasons to back your patch. In any case, I understand that the bug needs to be solved and if this is what it takes, then do it. FWIW, I also think suspend would be good here. - Aleix Pol Gonzalez On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 9:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 12:34 p.m., Aleix Pol Gonzalez wrote: > > I think it's unfortunate, you're giving a mix of technical and usability > > reasons to back your patch. In any case, I understand that the bug needs to > > be solved and if this is what it takes, then do it. > > > > FWIW, I also think suspend would be good here. Just out of interest: where am I mixing technical and usability reasons? To me the commit message sounds only technical. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68374 --- On Oct. 14, 2014, 11:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 11:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 10:34 a.m., Aleix Pol Gonzalez wrote: > > I think it's unfortunate, you're giving a mix of technical and usability > > reasons to back your patch. In any case, I understand that the bug needs to > > be solved and if this is what it takes, then do it. > > > > FWIW, I also think suspend would be good here. > > Martin Gräßlin wrote: > Just out of interest: where am I mixing technical and usability reasons? > To me the commit message sounds only technical. Well, it's not like it's not possible to shutdown from the lock screen. Many OS have done that in the past, thinking of Android, Windows (XP?), etc. So we can fix that, or disable it. So that's technical, while removing the functionality is the usability way to solve things. Disabling it is efficient on the other hand, because we already have this patch. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68374 --- On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 9:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 12:34 p.m., Aleix Pol Gonzalez wrote: > > I think it's unfortunate, you're giving a mix of technical and usability > > reasons to back your patch. In any case, I understand that the bug needs to > > be solved and if this is what it takes, then do it. > > > > FWIW, I also think suspend would be good here. > > Martin Gräßlin wrote: > Just out of interest: where am I mixing technical and usability reasons? > To me the commit message sounds only technical. > > Aleix Pol Gonzalez wrote: > Well, it's not like it's not possible to shutdown from the lock screen. > Many OS have done that in the past, thinking of Android, Windows (XP?), etc. > So we can fix that, or disable it. So that's technical, while removing the > functionality is the usability way to solve things. > > Disabling it is efficient on the other hand, because we already have this > patch. ok, I understand what you mean. But I think the comparison to other OS doesn't really fit as we have the session management and interaction. Android is designed differentelly with each application having to expect that it gets killed at any time anyway. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68374 --- On Oct. 14, 2014, 11:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 11:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 7:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 14, 2014, 9:02 a.m., 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. > > Kai Uwe Broulik wrote: > So, the button should also honor that policy? > > Martin Klapetek wrote: > > So, the button should also honor that policy? > > The thing is (I think) that having the button exposed
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- Relevant code in greeterapp needs removing too. There's a property and a slot ::shutdown() Interestingly the canShutDown is based on whether the user can logout which is a bit random. - David Edmundson On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 9:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Okt. 15, 2014, 8:30 nachm., David Edmundson wrote: > > Relevant code in greeterapp needs removing too. > > There's a property and a slot ::shutdown() > > > > Interestingly the canShutDown is based on whether the user can logout which > > is a bit random. > Relevant code in greeterapp needs removing too. all right, will update. > Interestingly the canShutDown is based on whether the user can logout which > is a bit random. yeah, I thought so as well when reading the documentation. What would be cool is to tell logind that currently the screen is locked and that logind behaves like there is no active session in that case. Maybe worth to take to their mailing list? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- On Okt. 14, 2014, 11:45 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, 11:45 vorm.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 15, 2014, 6:30 p.m., David Edmundson wrote: > > Relevant code in greeterapp needs removing too. > > There's a property and a slot ::shutdown() > > > > Interestingly the canShutDown is based on whether the user can logout which > > is a bit random. > > Martin Gräßlin wrote: > > Relevant code in greeterapp needs removing too. > > all right, will update. > > > Interestingly the canShutDown is based on whether the user can logout > which is a bit random. > > yeah, I thought so as well when reading the documentation. What would be > cool is to tell logind that currently the screen is locked and that logind > behaves like there is no active session in that case. Maybe worth to take to > their mailing list? We already do tell logind that the session is locked (or at least we should be), but as you pointed out earlier canShutdown is user based not session based so it doesn't really end up helping. It's worth an email, they might have a plan or at least they would want to know where logind maybe misses something for when they make v2. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 9:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
> On Oct. 15, 2014, 8:30 p.m., David Edmundson wrote: > > Relevant code in greeterapp needs removing too. > > There's a property and a slot ::shutdown() > > > > Interestingly the canShutDown is based on whether the user can logout which > > is a bit random. > > Martin Gräßlin wrote: > > Relevant code in greeterapp needs removing too. > > all right, will update. > > > Interestingly the canShutDown is based on whether the user can logout > which is a bit random. > > yeah, I thought so as well when reading the documentation. What would be > cool is to tell logind that currently the screen is locked and that logind > behaves like there is no active session in that case. Maybe worth to take to > their mailing list? > > David Edmundson wrote: > We already do tell logind that the session is locked (or at least we > should be), but as you pointed out earlier canShutdown is user based not > session based so it doesn't really end up helping. > > It's worth an email, they might have a plan or at least they would want > to know where logind maybe misses something for when they make v2. > We already do tell logind that the session is locked we do? How? ;-) I had looked at the interface and all I could see was the "lockSession" which asks the sessions to lock the screen (and we do that), but no way to tell logind that "it's locked now" and "it's no longer locked". - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- On Oct. 14, 2014, 11:45 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 14, 2014, 11:45 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/ --- (Updated Oct. 20, 2014, 7:59 a.m.) Review request for Plasma and Aleix Pol Gonzalez. Changes --- Remove shutdown also from greeter app. Bugs: 339453 https://bugs.kde.org/show_bug.cgi?id=339453 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 (updated) - ksmserver/screenlocker/greeter/greeterapp.cpp fd1d20b824dd7781cb5c2e96895694f290a46877 lookandfeel/contents/lockscreen/LockScreen.qml 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d ksmserver/screenlocker/greeter/greeterapp.h f3033c701fb3c3ce5fa8f12f58ee8c6af739444b 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68744 --- +1. and +1 for putting in 5.1 too. I don't really agree with you on the suspend discussion but it's clear we're not going anywhere on that soon and it shouldn't hold up removing shutdown which I think we do all agree on. - David Edmundson On Oct. 20, 2014, 5:59 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > --- > > (Updated Oct. 20, 2014, 5:59 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Bugs: 339453 > https://bugs.kde.org/show_bug.cgi?id=339453 > > > 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 > - > > ksmserver/screenlocker/greeter/greeterapp.cpp > fd1d20b824dd7781cb5c2e96895694f290a46877 > lookandfeel/contents/lockscreen/LockScreen.qml > 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d > ksmserver/screenlocker/greeter/greeterapp.h > f3033c701fb3c3ce5fa8f12f58ee8c6af739444b > > 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/ --- (Updated Nov. 3, 2014, 8:59 a.m.) Status -- This change has been marked as submitted. Review request for Plasma and Aleix Pol Gonzalez. Bugs: 339453 https://bugs.kde.org/show_bug.cgi?id=339453 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 - ksmserver/screenlocker/greeter/greeterapp.cpp fd1d20b824dd7781cb5c2e96895694f290a46877 lookandfeel/contents/lockscreen/LockScreen.qml 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d ksmserver/screenlocker/greeter/greeterapp.h f3033c701fb3c3ce5fa8f12f58ee8c6af739444b 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
