/proc/$pid/* gets too restrictive permissions for g-s-t tools

[Carlos Garnacho]

Binary package hint: gnome-system-tools

gnome-system-tools relies on PolicyKit to check privileges, and PolicyKit-gnome 0.6 requires reading /proc/$pid/exe to know the executable binary path, however this is what I get when running any g-s-t tool (didn't see it with other executables):

$ ps -ef | grep "network-admin"
carlos 9385 8497 0 20:35 pts/1 00:00:00 ./network-admin
$ ls -l /proc/9385/exe
ls: cannot read symbolic link /proc/9385/exe: Permission denied
lrwxrwxrwx 1 root root 0 2008-01-07 20:36 /proc/9385/exe

When pressing the "unlock" button, PolicyKit-gnome should show a dialog to ask for the user/admin password, but due to these permissions, it fails, g-s-t was incorrectly interpreting the error as a successful reply (fixed in svn trunk), but there's clearly a much bigger underlying problem, so the possible solutions are:

1) Check where does the /proc/$pid entry for g-s-t tools get such permissions and unpatch/fix it
2) Update to PolicyKit 0.7, where the exec path isn't anymore a hard requirement

I'm reporting it to the g-s-t package as it's where it's visible

[Sebastien Bacher (seb128)]

Thank you for the detail bug report, I've subscribed Martin who might know about the issue

[Martin Pitt (pitti)]

I confirm the /proc/pid/exe readlink failure. It doesn't work for g-s-t tools, but I can do it for other processes of mine.

I didn't upgrade PK to 0.7 yet because it does not work at all at least for me (tested with gnome-mount). Apparently the dbus API changed and the client apps need updates as well?

[Launchpad Janitor (janitor)]

This bug was fixed in the package policykit - 0.6-1ubuntu4

---------------
policykit (0.6-1ubuntu4) hardy; urgency=low

  * Disable 02_noptrace.patch for now, since disabling ptrace() also disables
    reading /proc/<pid>/exe and PK 0.6 depends on this. (LP: #181088)

 -- Martin Pitt <email address hidden> Tue, 08 Jan 2008 09:50:53 +0100

[Saivann Carignan (oxmosys)]

Tested latest hardy updates and changing root account with GST now works, thanks for your great work!

[Phoul (v-admin-insecure-complexity-com)]

This bug has been revived in the latest hardy update

[Emilio Pozuelo Monfort (pochu)]

Martin, it seems like you enabled that patch again:

    - debian/patches/02_noptrace.patch: Disable ptrace() for
      polkit-gnome-manager, to make it harder to silently abuse gained PK
      privileges. (See policykit-integration spec). Forwarded to FD#13742.

[Martin Pitt (pitti)]

I deliberately added the patch again since with 0.7 g-s-t works fine for me with the ptrace protection enabled. What exactly broke for you?

[Martin Pitt (pitti)]

Let's discuss this in bug 183673. I believe that this bug is fixed.