GitLab

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.

Also document in README why the various permissions/modes are
used. Thanks to Michael Biebl <biebl@debian.org> for pointing this
out.

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@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

More details at

 https://bugzilla.novell.com/show_bug.cgi?id=295341#c25

Add support for Solaris platform. The patch contains some implement
for GNU library extentsion function which isn't support by Solaris,
for instance, vasprintf(), strndup(), clearenv(), and clearenv(). Also
rewriting some code which Sun compiler doesn't support, such as empty
union name.

http://bugs.freedesktop.org/show_bug.cgi?id=15295

Add Piter PUNK's polkit-grant-helper-shadow, and link against the
appropriate libraries.

For now, the Shadow framework must be explictily called - in future,
this could also be added as a fallback if PAM is not available.

This is to avoid breaking various backup and IDS software - proposed
by Michael Biebl <mbiebl@gmail.com>.

As per discussions with David Zeuthen, alter the build system so that we
can have different authentication frameworks for the authorisation
databases.

For now, the dummy database will only accept 'none' for the authentication
framework (this will be autoselected if not specified, and configure will
throw an error if any other framework than 'none' is specified is passed
in).

For the default database, the only available framework for now is 'pam'
(as with 'none' and dummy, 'pam' will be autoselected if specified as the
framework. If 'none' is passed as a framework, configure will reject this
and fail).

PAM specific code is now also marked with POLKIT_AUTHFW_PAM, so that it
can be easily compiled out if other frameworks are added in future.

Suggested by Michael Biebl <mbiebl@gmail.com>.

getting closer...

$ grep glib *.c
polkit-authorization.c:#include <glib.h>
polkit-authorization-db.c:#include <glib.h>
polkit-authorization-db-dummy.c:#include <glib.h>
polkit-config.c:#include <glib.h>
polkit-context.c:#include <glib.h>
polkit-sysdeps.c:#include <glib.h>

This is what it looks like

==============================================================================
Test coverage for module polkit:
==============================================================================
polkit-sysdeps.c                                        :   0% (0 of 38)
polkit-error.c                                          :   0% (0 of 44)
polkit-result.c                                         :   0% (0 of 16)
polkit-context.c                                        :   0% (0 of 213)
polkit-action.c                                         :  34% (20 of 58)
polkit-seat.c                                           :   0% (0 of 34)
polkit-session.c                                        :   0% (0 of 97)
polkit-caller.c                                         :   0% (0 of 81)
polkit-policy-file-entry.c                              :   0% (0 of 72)
polkit-policy-file.c                                    :   0% (0 of 220)
polkit-policy-cache.c                                   :   0% (0 of 98)
polkit-policy-default.c                                 :   0% (0 of 67)
polkit-debug.c                                          :   0% (0 of 15)
polkit-utils.c                                          :   0% (0 of 42)
polkit-config.c                                         :   0% (0 of 263)
polkit-authorization.c                                  :   0% (0 of 162)
polkit-authorization-constraint.c                       :   0% (0 of 107)
polkit-authorization-db.c                               :   0% (0 of 222)

Source lines          : 6919
Actual statements     : 1849
Executed statements   : 20
Test coverage         : 1%

Right now we provide two methods

 IsProcessAuthorized
 IsSystemBusNameAuthorized

This is useful for a couple of reasons

 - some mechanisms (e.g. Avahi) runs in a chroot and their only
   life-line to the world is a system bus connection. If it were to
   use libpolkit (and Lennart says he wants it to, yay!) it would need
   to bindmount crazy stuff into the chroot.

 - languages for which libpolkit bindings not yet exist can use
   this interface

Going forward, this service can expose a private interface meaning we
can get rid of (almost) all of our setgid helpers.

Also,

 - Rename polkit-list-actions to polkit-action.
 - Add a bash completion script to the polkit commandline tools.

Authorizations are no longer world-readable. So for this to work with
hal you now need to do this as root

 # polkit-auth --user haldaemon --grant org.freedesktop.policykit.read

Distributions needs to do this in the %post scripts or similar.

Sorry for this huge monster patch.

Better late than never!

Patch from S.Çağlar Onur <caglar@pardus.org.tr>. Thanks.

Adds Gentoo as a valid OS type

 - Put all three libraries in the same gtk-doc project
 - Include the spec in the gtk-doc project
 - Include the manual pages in the gtk-doc project

So it turns out that I hadn't been using shadow passwords on my other
development box (don't ask) and that's why auth as root worked fine
when just running as an unprivileged user. However, to auth as another
user (such as root), the process embedding pam needs to run as
root. Therefore, split out the actual authentication bits into a small
and easy to audit helper, polkit-grant-helper-pam.

The auth now goes like this:

 polkit-gnome <-links with-> libpolkit-grant
                                   ^
                                   |
                                spawns
                                   |
                                   V
                     /usr/libexec/polkit-grant-helper
                                   ^
                                   |
                                spawns
                                   |
                                   V
                   /usr/libexec/polkit-grant-helper-pam

where

 polkit-grant-helper
    is setgid polkit; it links with libdbus and libpolkit.

 polkit-grant-helper-pam
    is setuid root; it links only with libpam

- change user from 'polkit' to 'polkituser'
- create directories in /var from polkit instead of polkit-grant

Descriptions will be subject to i18n/l10n efforts at some point.

Also add a new tool polkit-list-actions.

It's more consistent and, uhm, easier to type.

 - Split libpolkit into three libraries
   - libpolkit : to be used only by mechanisms and modules
   - libpolkit-dbus : utility library for libpolkit to get caller, session
                      etc. info from the bus and ConsoleKit
   - libpolkit-grant : client side library for obtaining privileges; uses
                       a setgid helper internally

 - grant functionality
   - a helper library, libpolkit-grant, to gain privileges
     - includes a setgid $POLKIT_GROUP helper to write granted privileges
   - a PK module, to read and interpret granted privileges
   - a cmdline app, polkit-grant, using said library

 - Other changes
   - so it turns out that sizeof(bool) != sizeof(gboolean), sizeof(dbus_bool_t)
     This blows so define our own polkit_bool_t type
   - add some validation routines

The grant functionality, especially the setgid helper needs thorough
security review before we can release it.

 Privilege -> Action
 PrivilegeFile -> PolicyFile
 PrivilegeFileEntry -> PolicyFileEntry
 PrivilegeCache -> PolicyCache

Hopefully it makes a bit more sense now.

This paves the way for writing

 1. A module that tracks temporary (look in /var/run) and permanent (look
    in /var/lib) privilege grants
 2. A D-Bus service to authenticate a client to obtain to a privilege
    grant and then writing the grant in temporary or permanent storage

Also, this feature lets people very easily lock down the system; just
edit /etc/PolicyKit/PolicyKit.conf; add pam-module-deny-all / -allow-all
stanzas with various privilege=<regexp> and user=<username> options.