1. 06 May, 2008 1 commit
  2. 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);
  3. 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
  4. 17 Apr, 2008 1 commit
  5. 16 Apr, 2008 1 commit
  6. 11 Apr, 2008 1 commit
  7. 10 Apr, 2008 1 commit
  8. 08 Apr, 2008 7 commits
  9. 04 Apr, 2008 1 commit
  10. 17 Mar, 2008 3 commits
  11. 04 Mar, 2008 7 commits
  12. 29 Feb, 2008 1 commit
  13. 28 Feb, 2008 2 commits
  14. 26 Feb, 2008 4 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.
    • Holger Macht's avatar
      avoid reliance on DT_REG so we work on reiserfs as well · 0b59d3e7
      Holger Macht authored
      (with minor fixes from davidz for avoiding memory leaks)
      Recently I wondered why PolicyKit (especially polkit-auth) does not work
      on my system. While debugging, I noticed that the corresponding code works
      in my home directory, but not in the root filesystem.
      readdir() and its d_type are the culprits. Quoting the readdir manpage:
      Other than Linux, the d_type field is available mainly only on BSD
      systems.  This field makes it possible to avoid the expense of calling
      stat() if further actions depend on the type of the file.
      Filesystems may fill DT_UNKNOWN into this field, which reiserfs does, so
      call stat instead, which always does the right thing.
      Signed-off-by: Holger Macht's avatarHolger Macht <hmacht@suse.de>
    • David Zeuthen's avatar
      avoid use normal timeout when showing auth dialog; use INT_MAX instead · fd51264a
      David Zeuthen authored
      Reported by Dan P. Berrange.
  15. 18 Dec, 2007 1 commit
  16. 17 Dec, 2007 3 commits