1. 31 Jul, 2008 1 commit
    • David Zeuthen's avatar
      bump to version 0.90 and ensure we're parallel installable with 0.9 · 2a356677
      David Zeuthen authored
      This is the first move towards 1.0; also
       - kill the config file
       - merge libpolkit and libpolkit-dbus
      Now to write a system daemon that libpolkit will use for the
      backend. Expect HEAD to be broken for a few weeks at least.
      Also see http://ometer.com/parallel.html for what "parallel
      installable" means. As a result, all the binaries, man pages, .policy
      file dir and so forth have been renamed too. I expect the API to
      change a bit. So some (not much though) porting to PolicyKit 1.0 will
      be required by current users.
  2. 22 Jul, 2008 4 commits
  3. 30 Jun, 2008 1 commit
  4. 06 May, 2008 1 commit
  5. 01 May, 2008 1 commit
    • Joe Clarke's avatar
      remove watch on fd when reaching EOF · a7e5318b
      Joe Clarke authored
      On Wed, 2008-04-30 at 16:30 -0400, David Zeuthen wrote:
      > On Wed, 2008-04-30 at 16:21 -0400, Joe Marcus Clarke wrote:
      > > David Zeuthen wrote:
      > > > On Wed, 2008-04-30 at 13:52 -0400, Joe Marcus Clarke wrote:
      > > >> David Zeuthen wrote:
      > > >>> On Wed, 2008-04-30 at 13:44 -0400, Joe Marcus Clarke wrote:
      > > >>>> Correct.  I think it does read all the data, then the stream puts out
      > > >>>> EOF which causes the helper to be called ad infinitum.
      > > >>> I see. Mmm.. In that case, polkit_grant_io_func() can detect EOF
      > > >>> (getline() returning -1) and then call the remove_watch() method
      > > >>> supplied by polkit-gnome-manager.c right?
      > > >> It could, but what's the difference between that and returning FALSE in
      > > >> the caller?  Both would result in the watch being removed.  And since
      > > >> the io_func reads the entire amount of data (until EOF) that shouldn't
      > > >> be a problem.
      > > >
      > > > The PAM conversation happens over that fd and for some cases I don't
      > > > think we read all the data at once. So there may be multiple calls to
      > > > polkit_grant_io_func(). As such, returning FALSE won't work for all
      > > > cases.
      > >
      > > It looks like it will (read all data).  The polkit_grant_io_func() runs
      > > in a while loop waiting for readline to return -1.  I don't see that
      > > this function ever returns to the caller until readline returns -1
      > > (signifying EOF or some other error).  Am I misunderstanding something?
      > No, you're right, that's how it works right now. But in the future this
      > function might return control back to the application and then it needs
      > to be called again by the watch when the application goes to process the
      > main loop.
      > Anyway, the other main reason I'd like polkit_grant_io_func() to call
      > remove_watch() as opposed to making io_watch_have_data() in
      > polkit-gnome-manager.c return FALSE is because of the fact that
      > PolicyKit-gnome is just one of many users of libpolkit-grant (others
      > right now are: polkit-auth(1), the PolicyKit-kde project that some
      > people are working on)
      That works.  Adding this hunk to polkit-grant.c fixes the problem:
      @@ -419,6 +420,8 @@ polkit_grant_io_func (PolKitGrant *polki
               if (line != NULL)
                       free (line);
      +        polkit_grant->func_remove_watch (polkit_grant, polkit_grant->io_watch_id);
  6. 30 Apr, 2008 5 commits
    • David Zeuthen's avatar
      fix typo · af9fdf86
      David Zeuthen authored
    • David Zeuthen's avatar
      fix autotools screwup · 8cd339bb
      David Zeuthen authored
      I hate autotools.
    • David Zeuthen's avatar
    • David Zeuthen's avatar
    • Joe Clarke's avatar
      add support for FreeBSD · 40c8b8ae
      Joe Clarke authored
      On Mon, 2008-04-21 at 15:06 -0400, David Zeuthen wrote:
      > On Sat, 2008-04-19 at 01:34 -0400, Joe Marcus Clarke wrote:
      > > I'm seeing a few PK problems on FreeBSD, but I'm not sure if this is a
      > > problem with our port, or an issue in general.  First, all of the tests
      > > David mentioned earlier (with polkit-auth) work.  The built-in tests
      > > also appear to work.  PK consumers also seem to work.
      > >
      > > What I'm noticing is that PolicyKit-gnome doesn't update in real-time.
      > > For example, if I launch polkit-gnome-authorization, then change a
      > > policy, the changes don't reflect in the GUI until I restart
      > > polkit-gnome-authorization.  Also, I'm not seeing any UI changes in
      > > polkit-gnome-example when I click on the various buttons (though
      > > polkit-gnome-manager does launch).
      > This suggests that file monitoring of /var/lib/misc/PolicyKit.reload is
      > somehow botched. Is polkit_context_io_func() in polkit-context.c ever
      > called if you do
      >  # touch /var/lib/misc/PolicyKit.reload
      > Is it called if you manually grant/revoke an authorization using
      > polkit-auth(1)? (And does /var/lib/misc/PolicyKit.reload change mtime
      > in that case?)
      Thanks for your advice.  I was not monitoring the reload file for
      attribute changes, so I was missing the mtime change.  That is working
      I updated the PK diff with the portability fix.  I didn't actually use
      the Solaris code as it caused a slew of compiler warnings and other
      problems.  Instead, I went with creating a kit-lib.[ch] to store the
      missing functions.  As for strndup(), I stuck that in kit-string.c.  I
      wrapped all of these functions with configure checks to avoid
      hard-coding OS checks.  This should make it easier to port PK to other
      I would still like your advice on the IO problem with PK-gnome.  I have
      changed io_watch_have_data() in polkit-gnome-manager.c to return FALSE
      instead of TRUE to auto-remove the IO watch.  As I said, FreeBSD's
      poll() continuously indicates EOF as a G_IO_IN condition until it is
      handled.  By returning FALSE here, the infinite loop is fixed, and I
      didn't notice any other problems.
      What problems could this cause?  Is there a better way of handling this?
      Joe Marcus Clarke
      FreeBSD GNOME Team      ::      gnome@FreeBSD.org
      FreeNode / #freebsd-gnome
  7. 17 Apr, 2008 1 commit
  8. 16 Apr, 2008 1 commit
  9. 11 Apr, 2008 1 commit
  10. 10 Apr, 2008 1 commit
  11. 08 Apr, 2008 7 commits
  12. 04 Apr, 2008 1 commit
  13. 17 Mar, 2008 3 commits
  14. 04 Mar, 2008 7 commits
  15. 29 Feb, 2008 1 commit
  16. 28 Feb, 2008 2 commits
  17. 26 Feb, 2008 2 commits
    • David Zeuthen's avatar
      make polkit-policy-file-validate require that actions are properly packaged · 2b1a2a69
      David Zeuthen authored
      Meaning this bit was added to the spec:
         The name of the XML file is significant. Each XML file can only
         declare actions from the namespace of it's own name; for example
         actions org.foobar.action-a, org.foobar.action-b and
         org.foobar.action-c would all go into the file org.foobar.policy
         while actions com.my-company.product-awesome.action-a,
         com.mycompany.product-awesome.action-b would go into the file
      This is the output of the validator on a broken .policy file
        $ polkit-policy-file-validate /usr/share/PolicyKit/policy/gnome-clock-applet-mechanism.policy
        WARNING: The action org.gnome.clockapplet.mechanism.configurehwclock does not
                 belong in a policy file named gnome-clock-applet-mechanism.policy.
                 A future version of PolicyKit will ignore this action.
        WARNING: The action org.gnome.clockapplet.mechanism.settime does not
                 belong in a policy file named gnome-clock-applet-mechanism.policy.
                 A future version of PolicyKit will ignore this action.
        WARNING: The action org.gnome.clockapplet.mechanism.settimezone does not
                 belong in a policy file named gnome-clock-applet-mechanism.policy.
                 A future version of PolicyKit will ignore this action.
        ERROR: /usr/share/PolicyKit/policy/gnome-clock-applet-mechanism.policy did not validate
      We currently don't enforce this but will in a future version. The
      rationale is that we can avoid loading all .policy files at startup
      which would be a performance win.
    • David Zeuthen's avatar
      fix doc in bugs for PolKitContextAddIOWatch · b3930e8b
      David Zeuthen authored
      pointed out by Dan Winship.