Testing PolicyKit

Joe Marcus Clarke marcus at FreeBSD.org
Mon Jan 7 10:05:37 PST 2008

Hash: SHA1

David Zeuthen wrote:
| On Mon, 2008-01-07 at 12:53 -0500, Joe Marcus Clarke wrote:
|> Hash: SHA1
|> David Zeuthen wrote:
|> | On Sun, 2007-12-23 at 03:28 -0500, Joe Marcus Clarke wrote:
|> |> I'm starting to bring the FreeBSD port of HAL up to 0.5.10, and this
|> |> requires a big PolicyKit overhaul.  I have successfully ported 0.7 to
|> |> FreeBSD (in that it builds without warnings or errors), but I
would like
|> |> to test it before going further.  I know there are unit tests, but
|> |> depend heavily on Linux, and I'd rather just get a few "real world"
|> |> examples to run through before moving on to the port of HAL itself.
|> |>
|> |> If there are some things I can try to confirm the port works,
please let
|> |> me know.  Once I know the port is working, I will forward on my
|> |> Thanks.
|> |
|> | What is so Linux specific about it? IIRC there are only three kernel
|> | specific functions, all nicely in src/polkit/polkit-sysdeps.c.
|> A lot is Linux-specific, actually:
|> * Assumes all platforms have clearenv(), strndup(), readdir64(), and
|> getline() (not true on FreeBSD and Solaris except for readdir64())
| This seems easily fixable, no?
|> * Requires Linux's inotify, and includes inotify.h in some places where
|> it doesn't need to
| Right, and this isn't really encapsulated very well... All we need is
| the ability to know when a file changes. So either we hide this behind
| an abstraction or we just just #ifdef's in the code? What would you
| prefer?
|> * Leaves out some important headers needed for compilation on non-Linux
|> platforms
| I presume easily fixable.
|> * And as you said, assumes a Linux /proc (in sysdeps)
| I think FreeBSD has a very similar interface; that was my conclusion
| looking at gnome-keyring.
|> I have created portability patches for each of these problems that
|> should be easily accepted upstream.
| Cool.

Yeah, all of these problems have been fixed, and I will send a patch
blob upstream when I get functionality confirmed (other patches may be

|> I would just like some hints on how to properly test it.
| The PolicyKit-gnome project
| http://gitweb.freedesktop.org/?p=users/david/PolicyKit-gnome.git;a=summary
| contains a small UI test app, polkit-gnome-example. There's also
| polkit-gnome-authorization which can be used to extensively test it.
| Also, just using polkit-auth from the PolicyKit project is a fine test;
| e.g.
| $ polkit-auth --user davidz --grant org.freedesktop.policykit.revoke
| polkit-auth: NotAuthorizedToGrantAuthorization: uid 500 is not
authorized to grant authorization for action
org.freedesktop.policykit.revoke to uid 500 (requires
| $ sudo polkit-auth --user davidz --grant org.freedesktop.policykit.revoke
| $ polkit-auth --explicit-detail
| org.freedesktop.policykit.revoke
|   Authorized:  Yes
|   Scope:       Indefinitely
|   Obtained:    Mon Jan  7 12:57:49 2008 from root (uid 0)
| $ polkit-auth --revoke org.freedesktop.policykit.revoke
| $ polkit-auth --explicit-detail


| And of course there's the existing test suite though it doesn't yet test
| much of the real API just yet.

And the test suite assumes even more Linux-specific /proc things (like
open files).  I thought it would be easier to test PK in some realish
scenarios rather than port the test suite.


- --
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome at FreeBSD.org
FreeNode / #freebsd-gnome
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the hal mailing list