graesslin added a comment.
On X11 I agree, there is no point in this change. On Wayland there is,
because on Wayland attacking the lock screen is the best way to gain user's
password.
REPOSITORY
rKSCREENLOCKER KScreenLocker
REVISION DETAIL
https://phabricator.kde.org/D797
EMAIL PREFERE
ahartmetz added a comment.
A good rule is that if you want to protect against a security issue, you must
first explain why the user is not already screwed.
If a malicious app is running and can disable the screen locker (or not), the
security state transition is from "the user is completely
graesslin added a comment.
I disagree on the point that if a malicious process is already running the lock
screen is the least to worry about. It's one of the items to worry about and
I'm trying to fix them all. It's just the first I picked.
Why is this one important: because it doesn't need a
davidedmundson added a comment.
> I must agree with David on this, generally having root own files in /home is
> a terrible idea.
Note it's not actually root owned. It gets set back to being owned by the user
but with "chattr -i" set by root.
REPOSITORY
rKSCREENLOCKER KScreenLocker
REVISI
mak added a subscriber: mak.
mak added a comment.
In https://phabricator.kde.org/D797#15210, @davidedmundson wrote:
> This breaks every user's backup script by having root files in the user's
> home. So I am very much not happy with this idea at all.
> Especially as it acheives very little anyw
davidedmundson added a comment.
In fact with this, you can now never remove a user. That's definitely a blocker
> When set, prevents, even the superuser, from erasing or changing the contents
> of the file.
INLINE COMMENTS
auth-helper/kscreenlockerauthhelper.cpp:94 Unintuitively, you're b
graesslin added a comment.
Another required change will be to mark the config file as immutable on startup
if it isn't already. I haven't included this yet as I want to get the basic
concept reviewed first.
INLINE COMMENTS
auth-helper/kscreenlockerauthhelper.cpp:34 As this is a linux-ism we
