Possible PolicyKit issues

Joe Marcus Clarke marcus at FreeBSD.org
Mon Apr 21 23:33:35 PDT 2008


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
now.

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
platforms.

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?
Thanks.

http://www.marcuscom.com/downloads/pk/

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/hal/attachments/20080422/4028f6d3/attachment.pgp 


More information about the hal mailing list