Development/Tutorials/PolicyKit/Helper HowTo - Revision history

AnneW at 12:43, 18 July 2012

2012-07-18T12:43:06Z

AnneW at 12:21, 18 July 2012

2012-07-18T12:21:13Z

Neverendingo: Text replace - "" to ""

2011-06-30T10:20:13Z

Text replace - "<syntaxhighlight lang="make">" to "<syntaxhighlight lang="cmake">"

Neverendingo: /* The last glue */

2011-06-29T19:57:56Z

‎The last glue

Neverendingo: /* DBus Activation */

2011-06-29T19:57:25Z

‎DBus Activation

Neverendingo: Text replace - "`" to ""`


2011-06-29T19:57:01Z
Text replace - "<code xml>" to "<syntaxhighlight lang="xml">"

				
				
				
				
			
			← Older revision
			Revision as of 19:57, 29 June 2011
			
Line 53:
Line 53:
  We suppose you already know how to create DBus interfaces from XML files. In our interface we need to specify the means of communication between the helper and the main application. Consider that the only way we have to talk to our helper is DBus, so we need to rely on signals and slots streamed through the Bus. In our foo application, we have a signal that tells us when the helper has completed the action. So:   We suppose you already know how to create DBus interfaces from XML files. In our interface we need to specify the means of communication between the helper and the main application. Consider that the only way we have to talk to our helper is DBus, so we need to rely on signals and slots streamed through the Bus. In our foo application, we have a signal that tells us when the helper has completed the action. So:
    
− <code xml> + <syntaxhighlight lang="xml">
  <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">   <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
  <node>   <node>
Line 72:
Line 72:
  Our helper will register itself on the system bus, as the session bus is reserved for the current user. DBus by default does not allow to register names on the System Bus, so we need a policy file for it. That's how it looks:   Our helper will register itself on the system bus, as the session bus is reserved for the current user. DBus by default does not allow to register names on the System Bus, so we need a policy file for it. That's how it looks:
    
− <code xml> + <syntaxhighlight lang="xml">
  <!DOCTYPE busconfig PUBLIC   <!DOCTYPE busconfig PUBLIC
    "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"     "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"

`Neverendingo: Text replace - "`" to ""

2011-06-29T19:42:23Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T19:38:50Z
Text replace - "<code cpp>" to "<syntaxhighlight lang="cpp">"

				
				
				
				
			
			← Older revision
			Revision as of 19:38, 29 June 2011
			
Line 30:
Line 30:
  What is cool about PolicyKit and this approach is that we need to write a minimum portion of code, don't need hacks or executon bits, and we actually get root privileges for a minimum portion of code. Suppose we still have our foo application we saw in the precedent Tutorial. From our .policy file, we know action2 actually does something that requires authentication as root. In fact, the following lines of code in action2 definitely require root privileges:   What is cool about PolicyKit and this approach is that we need to write a minimum portion of code, don't need hacks or executon bits, and we actually get root privileges for a minimum portion of code. Suppose we still have our foo application we saw in the precedent Tutorial. From our .policy file, we know action2 actually does something that requires authentication as root. In fact, the following lines of code in action2 definitely require root privileges:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  eraseHardDrive();   eraseHardDrive();
  killUser();   killUser();
Line 118:
Line 118:
  Our helper will consist of a single main class. Let's see how to do it:   Our helper will consist of a single main class. Let's see how to do it:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  class FooHelper : public QObject, protected QDBusContext   class FooHelper : public QObject, protected QDBusContext
  {   {
Line 136:
Line 136:
  The inheritance from QObject can be changed as you like, but '''inheriting from QDBusContext is compulsory.''' You'll understand why very soon. Let's define our constructor:   The inheritance from QObject can be changed as you like, but '''inheriting from QDBusContext is compulsory.''' You'll understand why very soon. Let's define our constructor:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  (void) new FooHelperAdaptor(this);   (void) new FooHelperAdaptor(this);
  if (!QDBusConnection::systemBus().registerService("org.kde.foohelper")) {   if (!QDBusConnection::systemBus().registerService("org.kde.foohelper")) {
Line 151:
Line 151:
  We simply connect to the '''system bus (be careful, not the session one!)''', and if something fail we quit, because it's quite likely that we're going over something weird. Now that we have done that and our application is inside it's main loop, it's time to see what action2() should do:   We simply connect to the '''system bus (be careful, not the session one!)''', and if something fail we quit, because it's quite likely that we're going over something weird. Now that we have done that and our application is inside it's main loop, it's time to see what action2() should do:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  void FooHelper::action2()   void FooHelper::action2()
  {   {
Line 199:
Line 199:
  Sure, we could use some signaling to trigger authorization, but Polkit-qt already provides us a really nice and easy method to manage the authentication automatically. Let's see how:   Sure, we could use some signaling to trigger authorization, but Polkit-qt already provides us a really nice and easy method to manage the authentication automatically. Let's see how:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  PolkitQt::ActionButton *bt = new PolkitQt::ActionButton(m_action2Button, "org.kde.foo.action2", this);   PolkitQt::ActionButton *bt = new PolkitQt::ActionButton(m_action2Button, "org.kde.foo.action2", this);
  bt->setText("Trigger Action2");   bt->setText("Trigger Action2");
Line 216:
Line 216:
  We are almost done, we just need to define performAction2(). That's it:   We are almost done, we just need to define performAction2(). That's it:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  void FooImportantClass::performAction2()   void FooImportantClass::performAction2()
  {   {



Drf at 17:36, 3 September 2009
2009-09-03T17:36:14Z


				
				
				
				
			
			← Older revision
			Revision as of 17:36, 3 September 2009
			
Line 13:
Line 13:
  reading=None   reading=None
  }}   }}
  + 
  + == WARNING: THIS TUTORIAL IS OBSOLETE. PLEASE USE THE NEW KAUTH FRAMEWORK INSTEAD (TUTORIAL WILL BE UPDATED SOON) ==
    
  == Before you start ==   == Before you start ==





Tampakrap: Updating to polkit-qt 0.9.2
2009-04-09T15:53:23Z
Updating to polkit-qt 0.9.2

				
				
				
				
			
			← Older revision
			Revision as of 15:53, 9 April 2009
			
Line 22:
Line 22:
    
  If you are aware of this, and you're also sure that your application actually needs root privileges, you can go on reading.   If you are aware of this, and you're also sure that your application actually needs root privileges, you can go on reading.
  + 
  + This tutorial assumes you're using Polkit-Qt >= 0.9.2
    
  == What we need to do ==   == What we need to do ==
Line 152:
Line 154:
       qDebug() << "Starting DB Update";        qDebug() << "Starting DB Update";
    
−      PolKitResult result; +      PolkitQt::Auth::Result result;
       result = PolkitQt::Auth::isCallerAuthorized("org.kde.foo.action2",        result = PolkitQt::Auth::isCallerAuthorized("org.kde.foo.action2",
                                         message().service(),                                          message().service(),
                                         true);                                          true);
−      if (result == POLKIT_RESULT_YES) { +      if (result == PolkitQt::Auth::Yes) {
           qDebug() << message().service() << QString(" authorized");            qDebug() << message().service() << QString(" authorized");
       } else {        } else {
Line 178:
Line 180:
    
  * Check through Polkit-qt if the caller was authorized. Using the DBus name also grants us that the action can be called through DBus only.   * Check through Polkit-qt if the caller was authorized. Using the DBus name also grants us that the action can be called through DBus only.
− * If the result is not POLKIT_RESULT_YES, we simply quit, as we are not authorized to do the action. You can obviously provide means of authentication here, but we are supposing (in this tutorial) that you are doing this from the main application + * If the result is not Auth::Yes, we simply quit, as we are not authorized to do the action. You can obviously provide means of authentication here, but we are supposing (in this tutorial) that you are doing this from the main application
    
  So the security happens here: if PolicyKit says no, we simply quit out. This way, only authorized application will be able to get through the real method.   So the security happens here: if PolicyKit says no, we simply quit out. This way, only authorized application will be able to get through the real method.
Line 245:
Line 247:
  dbus_add_activation_system_service(org.kde.foohelper.service.in)   dbus_add_activation_system_service(org.kde.foohelper.service.in)
    
− install(FILES org.kde.foohelper.conf DESTINATION /etc/dbus-1/system.d) + install(FILES org.kde.foohelper.conf DESTINATION ${SYSCONF_INSTALL_DIR}/dbus-1/system.d)
  install(FILES org.kde.foohelper.policy DESTINATION ${POLICY_FILES_INSTALL_DIR})   install(FILES org.kde.foohelper.policy DESTINATION ${POLICY_FILES_INSTALL_DIR})
  </code>   </code>

← Older revision		Revision as of 12:43, 18 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Development/Tutorials/PolicyKit/Helper_HowTo}}~~	+

	{{TutorialBrowser\|		{{TutorialBrowser\|

@@ Line 1: / Line 1: @@
-{{Template:I18n/Language Navigation Bar|Development/Tutorials/PolicyKit/Introduction}}
+{{Template:I18n/Language Navigation Bar|Development/Tutorials/PolicyKit/Helper_HowTo}}
 {{TutorialBrowser|
@@ Line 14: / Line 14: @@
 }}
-== WARNING: THIS TUTORIAL IS OBSOLETE. PLEASE USE THE NEW KAUTH FRAMEWORK INSTEAD (TUTORIAL WILL BE UPDATED SOON) ==
+{{
 == Before you start ==

@@ Line 100: / Line 100: @@
 This is where the fun starts. DBus gives us an impressive and powerful functionality: DBus activation. By defining a simple .service file, DBus will take care of activating the interface (and so the program) for us. Let's see this in detail:
-<code>
+<syntaxhighlight lang="ini">
 [D-BUS Service]
 Name=org.kde.foohelper

@@ Line 35: / Line 35: @@
 detonatePC();
 runAsFastAsYouCan();
-</code>
+</syntaxhighlight>
 But foo is a huge program that runs as standard user apart from those lines. So the option is to make it run as root as a whole, or split those 4 lines in a different program running as root. That is the approach that we will take in this tutorial.
@@ Line 63: / Line 63: @@
     </interface>
 </node>
-</code>
+</syntaxhighlight>
 And that's enough. Remember to specify in the interface any needed signal/slot to communicate with the main application or library.
@@ Line 91: / Line 91: @@
 </busconfig>
-</code>
+</syntaxhighlight>
 What does this file implies? It tells DBus that only root can register the name org.kde.foohelper on the System Bus (so that we avoid misusage), and anyone is allowed to call or receive signals from it. Don't worry about security: this will come later.
@@ Line 105: / Line 105: @@
 Exec=@LIBEXEC_INSTALL_DIR@/foohelper
 User=root
-</code>
+</syntaxhighlight>
 You might already have understood what this files tells DBus to do: whenever someone calls a method on org.kde.foohelper, if the interface is not present on the bus, DBus takes care of starting foohelper, that will provide the interface, and then call the method. The magic of starting it as root happens by appending "User=root". There is nothing else you have to do: now your helper is ready to be auto-activated as the root user.
@@ Line 132: / Line 132: @@
 signals:
      void action2Completed();
-</code>
+</syntaxhighlight>
 The inheritance from QObject can be changed as you like, but '''inheriting from QDBusContext is compulsory.''' You'll understand why very soon. Let's define our constructor:
@@ Line 147: / Line 147: @@
      QCoreApplication::instance()->quit();
+}
-</code>
+</syntaxhighlight>
 We simply connect to the '''system bus (be careful, not the session one!)''', and if something fail we quit, because it's quite likely that we're going over something weird. Now that we have done that and our application is inside it's main loop, it's time to see what action2() should do:
@@ Line 177: / Line 177: @@
      emit action2Completed();
+}
-</code>
+</syntaxhighlight>
 Let's see this in detail. The '''FIRST THING you always have to do is calling the authorization check, otherwise everything will be useless'''. As you can see, we are using message().service() from QDBusContext, hence the compulsory inheritance. What we are doing boils down to:
@@ Line 207: / Line 207: @@
 connect(bt, SIGNAL(clicked(QAbstractButton*, bool)), bt, SLOT(activate()));
 connect(bt, SIGNAL(activated()), this, SLOT(performAction2()));
-</code>
+</syntaxhighlight>
 And that's it: the slot performAction2() will be called when the user will get the authorization. Everything else will be done for you, dialog included.
@@ Line 233: / Line 233: @@
      QDBusConnection::systemBus().call(message, QDBus::NoBlock);
+}
-</code>
+</syntaxhighlight>
 That's it. Why is it so easy? Let's remember that:
@@ Line 251: / Line 251: @@
 install(FILES org.kde.foohelper.conf DESTINATION ${SYSCONF_INSTALL_DIR}/dbus-1/system.d)
 install(FILES org.kde.foohelper.policy DESTINATION ${POLICY_FILES_INSTALL_DIR})
-</code>
+</syntaxhighlight>
 Remember that you need to include FindPolkitQt.cmake to access some macros.

@@ Line 246: / Line 246: @@
 We are done. The last glue we miss lies in CMake. Our special files should be handled like this:
-<syntaxhighlight lang="make">
+<syntaxhighlight lang="cmake">
 dbus_add_activation_system_service(org.kde.foohelper.service.in)