[PATCH] dbus-spec: introduce new PERMIT_INTERACTIVE_AUTHENTICATION

[Lennart Poettering]

On Wed, 03.09.14 12:23, Thiago Macieira (thiago at kde.org) wrote:

> On Wednesday 03 September 2014 20:26:22 Lennart Poettering wrote:
> > +                <entry><literal>PERMIT_INTERACTIVE_AUTHENTICATION</literal>
> > </entry> +                <entry>0x4</entry>
> > +                <entry>This is a hint that may be set on a method call
> > +                message that informs the receiving side that the
> > +                caller is OK if possibly time-intensive interactive
> > +                user authentication may take place before the method
> > +                call will complete. A client may set this flag if it
> > +                is prepared to wait for a longer time before the
> > +                method call returns, and if its UI may be interrupted
> > +                by interactively querying the user for passwords or
> > +                confirmation. This flag is only useful when
> > +                unprivileged code calls a more priviliged method call,
> > +                and an authentication framework is deployed that
> > +                allows possibly interactive authentication. If no such
> > +                framework is deployed it has no effect. This flag
> > +                should not be set by default by client
> > +                implementations. If it is set the caller also should
> > +                set a suitably long timeout on the method call to make
> > +                sure the user interaction may complete. This flag is
> > +                only valid for method call messages, and shall be
> > +                ignored otherwise.
>
> How about removing the part about authentication and privileges, simply make
> the flag indicate that the caller is ok with a lengthy operation from the
> callee?

Well, I think we should find a middle ground between being too generic
and being too specific: specify enough to make this strictly useful,
but not more. I think apps will need to know the purpose of the delay,
just "delay" is not enough. They don't need to know precisely the
implementation used in the backend (i.e. whether it is the tizen thing
or polkit, or whatever else), but they should know whether this is
about authentication. Why? think about how this will be used: maybe
some tool is configured to automatically set the timezone when one is
learnt via network localization or such. If the user has turned this
on this doesn't mean though the admin actually allows him that. Now,
since this is suppsoed to be something completely automatic, under no
circumstances the user should be queried for auth each time this tool
gets triggered, which might be basically each time you connect to a
new WLAN. I mean, the point of the feature is to be automatic, and
hence without interaction. Popping up an auth box each time you
connect to a new WLAN would be crap UI. Now, if we make clear that
this bit is about auth, then the tool could just set it, and whenever
it learns a new timezone it would execute the operation, knowing that
if the admin disallowed this behaviour nothing will pop-up. Hence you
get the desired UI flow, without interrupting the user for auth in
this cases, if the admin turned of perms.

Anyway, you get the idea, apps need to know what they enabled
there. Genericly enough, but still know that this is about auth.

Also, I am not sure what else could be hidden behind this than auth,
and I don't want to define a spec for stuff I know nothing about.

So, I am absolutely sure we should make clear that this is about auth,
nothing else.

Lennart

--
Lennart Poettering, Red Hat