[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: KCM Authorization (was: Re: Review Request: print-manager on kdereview)
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2012-08-29 20:32:07
Message-ID: CAFFVnfNNJtU8r=zCb2a3sYycQ70DDUhax5d1=o992Nvr-jyM0A () mail ! gmail ! com
[Download RAW message or body]

2012/8/29 Thomas L=FCbking <thomas.luebking@gmail.com>:
> Moving to kwin.
>
> Am 29.08.2012, 03:15 Uhr, schrieb Dario Freddi <drf54321@gmail.com>:
>
>> The root of the problem is not in KAuth (which has been already
>> redesigned in Frameworks to be completely async, btw) but in the fact
>> that polkit doesn't conceive a window manager which makes the
>> authorization dialog non-modal.
>
>
> The modality description in the NETWM is extremely weak ("while clients c=
an"
> ... "WM can also" ... *sigh*) and there's no icccm defined concept of
> modality but the bottom line is that the user can not interact with the
> blocked window at all.

Sorry I explained myself really badly in the previous mail: the
problem is that polkit assumes that the authorization dialog will be
*system-wide modal* as in: no any other interaction can happen before
the dialog has been "completed".

> KWin so far (compiz eg. as well) only prevents passing the input focus to=
 a
> modally blocked client, but other events (notably mouse events) are still
> let through (and then blocked by the client)
>
> Because of the ultra weak specification we could probably change that w/o
> breaking the NETWM spec the least (we probably could also just unmap the
> blocked window w/o breaking the spec....) but that will of course not help
> with other WMs

As said above, we do not really care - KDE is the only environment
where we don't impose system-wide modality to the authorization dialog
and the case is so specific we can afford having something
KWin-specific IMHO

> This does however not cover programmatic exits.
> It's not possible (from the WM) to intercept signals (but they do oc not
> send SIGTERM on pressing the close button) and it's completely* impossible
> to block exit() calls that derive elsewhere.

In this case KAuth can do something though - I will need to add more
interaction and monitoring, but it's totally fine if we can finally
fix this.

> If however input is prevented, stopping the client in addition *might* be=
 an
> option (you stop more than that one window, it's kind of application moda=
l)

There is, however, another side of the medal which is the unsolvable
part: all of this will happen for clients using KAuth and NOT polkit
directly. As I said in the previous mail, KAuth already does a couple
hacks into polkit's handshake to allow the dialog and the client to
identify each other and parent. But if $application using polkit will
ask for authorization directly from polkit's APIs, all of this will be
useless anyway. It's not really something we can overcome, but just to
give a full overview of what we're up to.

P.S.: Thanks for caring about the issue
P.P.S.: Please keep me CC'ed, not subscribed.
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]