semantics of POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION

[Miloslav Trmač]

Hello,
----- Original Message -----
> So far I've been able to make that work on the server side. However I am
> very confused with the polkit_authority_check_authorization flag.
> 
> The API reference mentions "Note that
> POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION SHOULD be passed
> ONLY if the event that triggered the authorization check is stemming
> from an user action, e.g. the user pressing a button or attaching a
> device.".
> 
> However, that feels a bit confusing. A server like the one I describe
> can never know that. What do I do in that case, do I set the flag or
> not?
That's difficult.

> What are the implications of setting the flag when a
> non-interactive application is accessing the server?
If the authorization result is a "challenge" (polkit_authorization_result_get_is_challenge), polkitd without the flag just returns the "challenge" result.

With the flag, polkitd tries to search for a registered authentication agent, and asks that agent to authorize the operation.  If no agent is registered (e.g. a system daemon running outside of an user session with its own UID), polkitd will again just return the "challenge" result.

If there _is_ a registered agent, it will be prompted to authorize the operation (which typically displays a password dialog), and the calling application (== your server) will not get a reply to the authorization request until the user either enters a password or cancels the dialog.


In general, if your protocol doesn't tell you whether the user is involved in the operation or not, asking for user's password is a problem.

In the case of smart cards (which I assume is the concern), it might be reasonable to disable user interaction, and by default authorize access to an active user session (in the same logic as an owner of an active user session is automatically "authorized" to use the keyboard and mouse); this would let the sysadmin authorize e.g. httpd to access the card but allow it by default.  This suggestion, however, glosses over whether anything needs to be done when the active user session changes due to fast user switching.
     Mirek