Possible PolicyKit issues

[David Zeuthen]

Hi,

Sorry for the lag. My main laptop wasn't working so I was stuck on
another system until I got it fixed yesterday.

On Tue, 2008-04-22 at 02:33 -0400, Joe Marcus Clarke wrote:
> 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've committed that patch and also fixed up a few issues where libkit.la
wasn't being linked with some helpers.

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

There are two watch functions in polkit-gnome-manager.c

 1. io_watch_have_data
  - that calls polkit_grant_io_func()

 2. pk_io_watch_have_data
   - that calls polkit_context_io_func().

The problem you report is for 1., is that correct? I'm not sure we want
to remove the watch. I think we should rather fix polkit_grant_io_func()
to read all the data instead. I wonder why it's not doing that...

     David