KDM plans and lightDM

[Thomas Lübking]

Am Mon, 13 Jun 2011 16:46:12 -0400
schrieb Shaun Reich <predator106 at gmail.com>:

> Of course *a*. I even went out of my way to specify it in other blog
> entries, multiple times iirc.
Sorry, I don't read your blog - just did a quick google and thought this
was the best place to get a reliable answer.


OFF TOPIC ----------------
> It isn't just about the look. 
Other quick google up.

http://sreich.blogspot.com/2010/01/kdm-and-plasma-future.html
"using the same theming system"
"Line edits, button mouseover, click events and more, will all look
nice and at home with the rest of the system"
"Wallpapers will be fun also."
"From a clock, battery monitor, the kdm greeter (of course. you know,
the login dialog), system monitors, disc usage, sticky notes,
calculator, on-screen keyboard"

You got a better link why else using plasma is great?
Oh, and did you see "on-screen keyboard"?

> But you have fun with implementing that.
> I'd love to know how flexible and clean the code is </sarcasm>
You mean, like compared to the current indirect qwidget -> subclass ->
plasma -> 
-> svg
-> (incomplete) qstyle usage ..?

which usually fails (used to?, actually not tried lately) if you deviate
from oxygen's margins & paddings because it (implicitly) uses (used? no
idea whether this has ever been fixed) the style to calculate the size
but the theme paddings to render clipped strings?
/OFF TOPIC ---------------- 

> A "hostile" environment? If they have access to your PC you're screwed
This is not what i'm talking about. A "hostile" area is where many ppl.
have (in doubt non physical) access to the same machine.
So if user x can get user y to add a malicious plasmoid to the DM
frontend, he can pot. scam his login data/password and use that later
on.

Especially the KDM frontend is not the best location for permission
leverage attempts.


> The sysadmin would easily be able to prevent any additional plasmoids
> from being added.
Ahhh... security by opt-out. Of course, because anything else
would render the system pointless in the first place.

I however don't worry about professionally administrated systems at all
(because such things rather won't show up there, by no means) but the
small-to-mid (or just badly) semi administrated stuff (which is
apparently the core audience for this as well) - maybe run a query on
kde-apps on who uses or even knows about kiosk.

> Not only that, the applets only run as user. 
I did not expect the foreground process on root permissions anyway.

> So if the sysadmin did not disable that, and the user can add
> them...tell me..what are they going to do?

Overlay the input fields?
Scam logins & passwords?
Maybe just hook on textChanged signals for that purpose?

I haven't read the code, so i frankly don't know what kind of security
levels you've added to prevent such, but it is dangerous (as
mentioned: not in the meaning of leverage, but information gathering)

And really, since the DM greeter is a 3 second "see, type, enter" thing,
I wonder why anybody should add any kind of risk level for some stupid
custom clock there.

Maybe i'm just too old now, but i do really not see the
least reason for that at all.

Cheers,
Thomas