Development/Tutorials/PolicyKit/Introduction: Difference between revisions

    From KDE TechBase
    No edit summary
    (More stuff)
    Line 58: Line 58:
    </policyconfig>
    </policyconfig>
    </code>
    </code>
    Let's see how we wrote it:
    * action id is the unique identifier for our action. It is a nice convenience to set it as <your app's dbus interface>.<action name>
    * description is what your action actually does
    * message is the message that will be displayed when authorization or a negative result is shown to the user. It starts usually with prevents, as the string that will be displayed will be "System policy <message>".
    * under defaults we usually have to set 2 parameters: allow_inactive and allow_active. Those refer to the active/inactive console in the system. It is a good practice to set auth_inactive to no. Defaults set the default policy for this action in the specified cases. It can be one of:
    *# auth_self if authentication as the current user is required
    *# auth_admin if authentication as an administrator is required
    You can also append:
    *# _keep_session if you want the auth to be retained for the whole session
    *# _keep_always if you want the auth to be retained indefinitely
    *# _one_shot if you want the auth to be valid for performing the action just a single time

    Revision as of 21:28, 9 March 2009


    Development/Tutorials/PolicyKit/Introduction


    Introduction to PolicyKit
    Tutorial Series   PolicyKit Tutorial
    Previous   DBus activation, Basic DBus knowledge, Basic polkit-qt knowledge
    What's Next   Using the caller-helper model to perform actions as root
    Further Reading   None

    What is PolicyKit

    PolicyKit is an authentication system, that lets developers set a policy on specific actions. It works in strict correlation with DBus and ConsoleKit, and it is really useful in cases where you need to perform privileged actions

    Who is this tutorial for?

    This tutorial is aimed to developers who want their application to perform privileged actions in a secure, consistent and easy way.

    PolicyKit and KDE

    PolicyKit is closely integrated with KDE starting from version 4.3. In kdebase-workspace we have an authorization manager and an authentication agent. What matters the most, though, is polkit-qt library, in kdesupport, that lets us use the PolicyKit library through a nice Qt-styled API. In this tutorial we will be using it as our main development resource.

    Prerequisites

    Your application does not need very special prerequisites to be integrated with PolicyKit. Console applications or libraries can also link to polkit-qt-core, that doesn't add a dependency to QtGui.

    As a developer, you probably need to read the Polkit-qt api documentation, that is a fundamental compound of this tutorial. A fair knowledge of DBus (have a look at the DBus tutorial series for that) can make your workflow better.


    Special files used by PolicyKit

    Before you start diving into PolicyKit integration, you have to know how a .policy file is made. Those files contain a definition of actions carried out by your application that require authorization by PolicyKit. So let's suppose we are creating the application foo that can do action1, that requires authentication as the current user, and action2, that requires authentication as an administrator. Our policy file will be named org.kde.foo.policy and will look like this:

    <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE policyconfig PUBLIC

    "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
    

    <policyconfig>

     <action id="org.kde.foo.action1">
       <description>Action number one</description>
       <message>Prevents from doing action one</message>
       <defaults>
         <allow_inactive>no</allow_inactive>
         <allow_active>auth_self</allow_active>
       </defaults>
     </action>
    
     <action id="org.kde.foo.action2">
       <description>Action number two</description>
       <message>Prevents from doing action two</message>
       <defaults>
         <allow_inactive>no</allow_inactive>
         <allow_active>auth_admin</allow_active>
       </defaults>
     </action>
    

    </policyconfig>

    Let's see how we wrote it:

    * action id is the unique identifier for our action. It is a nice convenience to set it as <your app's dbus interface>.<action name>
    * description is what your action actually does
    * message is the message that will be displayed when authorization or a negative result is shown to the user. It starts usually with prevents, as the string that will be displayed will be "System policy <message>".
    * under defaults we usually have to set 2 parameters: allow_inactive and allow_active. Those refer to the active/inactive console in the system. It is a good practice to set auth_inactive to no. Defaults set the default policy for this action in the specified cases. It can be one of:
    *# auth_self if authentication as the current user is required
    *# auth_admin if authentication as an administrator is required
    

    You can also append:

    *# _keep_session if you want the auth to be retained for the whole session
    *# _keep_always if you want the auth to be retained indefinitely
    *# _one_shot if you want the auth to be valid for performing the action just a single time