Bug 19469

Summary:	polkit_check_auth does not use real uid as documented
Product:	PolicyKit	Reporter:	Matt McCutchen <matt>
Component:	libpolkit	Assignee:	David Zeuthen (not reading bugmail) <zeuthen>
Status:	RESOLVED INVALID	QA Contact:	David Zeuthen (not reading bugmail) <zeuthen>
Severity:	major
Priority:	medium
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Wrapper program exhibiting the problem Fix

Description Matt McCutchen 2009-01-08 10:53:45 UTC

I'm writing a simple setuid-root wrapper for a program that checks whether an external disk is in use (the root power is necessary to check device-mapper dependencies such as LUKS-opened partitions), and I'd like to use polkit_check_auth to control who can use the wrapper.  Following the PulseAudio example in the documentation, I passed getpid().

polkit_check_auth seems to be using the process's effective uid (which is root), not the real uid (matt) as the documentation claims.  Thus, it spawns "polkit-read-auth-helper 0", which inherits real uid matt and effective uid root.  polkit-read-auth-helper checks the "org.freedesktop.policykit.read" action since its real uid is neither root nor the user being queried, and this means spawning another polkit-read-auth-helper.  The result is an infinite recursion of polkit-read-auth-helper processes until the D-Bus connection limit is reached, rendering the wrapper useless.  If polkit_check_auth used the real uid as claimed, the first polkit-read-auth-helper would succeed.

Comment 1 Matt McCutchen 2009-01-08 11:07:51 UTC

polkit_check_auth is relying on polkit_caller_new_from_pid, which takes the owner of the target process's /proc/PID directory.  Linux returns the effective uid as the directory owner.  polkit_caller_new_from_pid will have to read /proc/PID/status to determine the real uid, just like procps does.

I should add that I'm using Fedora's PolicyKit-0.9-4.fc10.i386, but the relevant code appears to be unchanged in the latest development version.

Comment 2 Matt McCutchen 2009-01-08 11:16:50 UTC

Created attachment 21811 [details]
Wrapper program exhibiting the problem

Comment 3 Matt McCutchen 2009-01-08 11:19:18 UTC

Is it practical to call procps's libproc-X.Y.Z.so to determine the real uid, or will the code have to be duplicated in PolicyKit?

Comment 4 Matt McCutchen 2009-01-08 13:28:49 UTC

Created attachment 21815 [details] [review]
Fix

I decided to reimplement the parsing of /proc/PID/status for the real uid.  It wasn't so bad.

Comment 5 David Zeuthen (not reading bugmail) 2009-10-21 10:39:19 UTC

This bug report is for the old version of PolicyKit. Closing as all of the code has been rewritten. Please reopen if the bug report applies to the latest version of PolicyKit. Thanks.

Comment 6 Matt McCutchen 2009-10-21 13:30:56 UTC

This is a misuse of the INVALID resolution as described in the Bugzilla docs.  Please find a different way to mark obsolete bugs.  See:

https://bugzilla.redhat.com/show_bug.cgi?id=528319

(I do plan to retest ASAP and either reopen this bug or mark it WORKSFORME.)

Comment 7 Matt McCutchen 2009-11-04 23:50:51 UTC

There does not appear to be any analogue to this bug in the new PolicyKit.  The polkit_check_auth function no longer exists, and since authorization checks are done by a dbus service, there is no possibility for a non-root real uid to confuse things.  The check still seems to be based on effective uid, but the documentation no longer states otherwise, and I can live with that by having my wrapper temporarily set the effective uid to match the real uid.  I'll leave the bug INVALID because I really can't think of any better resolution, even though it was valid at the time it was reported.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.