Fun with Polkit - Textmode! Help!

[Luther_Blisset]

So F12 has no Polkit UI, and We, I, You need to rely on editing text files.

I tried reading the man pages for polkit, but they are confusing the hell out of me.

basically, what I want to do is: have packagekit ask users for the root password every time something gets installed.

not just when untrustworthy things are to be or things get removed.

how/where do I modify the files?

[Dies]

Umm, isn't that already the default behavior to ask every time?

Pretty sure it is, I had to switch mine to "don't ask, just do it" mode manually.

[Milena]

Originally Posted by Luther_Blisset

So F12 has no Polkit UI

yum install policycoreutils-gui

its not installed by default anymore.

[Luther_Blisset]

Originally Posted by Milena

yum install policycoreutils-gui

its not installed by default anymore.

no, that is not the right one.

policycoreutils-gui is for SELinux.

I am talking about polkit-gnome-authorizations or something to that extent, that manages, for example, authorizations to install trusted files. asking for passwords to install programs, asking for permission to uninstall files, mounting disks, and all that.

which does not exist in f12.

Originally Posted by Dies

Umm, isn't that already the default behavior to ask every time?

Pretty sure it is, I had to switch mine to "don't ask, just do it" mode manually.

once you set it, how do you revoke it again?

[Milena]

sorry i mixed up selinux gui and policytoolkit because the selinux one was not installed either

[Dies]

Originally Posted by Luther_Blisset

once you set it, how do you revoke it again?

As far as I know, in F12 you need to include your own policy in /var/lib/polkit-1. So the answer to your question is to either delete or modify the policy you installed.

If there are other ways to do it I'm sorry I'm not familiar with them.

On my installation the default behavior was to ask every single time with no option to keep authorization, which is what you said you want so... yeah... not sure why you need to change anything.

I ran across this on planet fedora, hope it helps

polkit and package kit and changing settings

In f12 the default policy for polkit for package kit is to allow users at the
desktop to install signed pkgs from repositories enabled on the system.

Some folks are unhappy about this so I investigated a bit. Ray Strode looked
through the polkit code to figure out the answers.

The short answer is to run (as root)

pklalockdown –lockdown org.freedesktop.packagekit.package-install

to remove this lockdown run (as root):

pklalockdown –remove-lockdown org.freedesktop.packagekit.package-install



Update: According davidz in the comments below the above command is going away. So if you want to keep users from installing pkgs you need to follow the longer instructions below.


the long answer explains a bit about polkit.

To get a list of all actions that policykit knows about you run:

pkaction

to get information about the system defaults for any action you run:

pkaction –action-id actionname –verbose

this only tells you what the system defaults are. It doesn’t tell you what
the current runtime policy is going to do.

examples:
pkaction –action-id org.freedesktop.packagekit.package-install –verbose

org.freedesktop.packagekit.package-install:
description: Install signed package
message: Authentication is required to install a signed package
vendor: The PackageKit Project
vendor_url: http://www.packagekit.org/
icon: package-x-generic
implicit any: no
implicit inactive: no
implicit active: yes

Now, if I want to change the value of this to something more specific you need
to edit a file:
/var/lib/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla

in this file you would put:

[Only Let Admins Install Packages]
Identity=unix-user:*
Action=org.freedesktop.packagekit.package-install
ResultAny=auth_admin
ResultInactive=auth_admin
ResultActive=auth_admin

save it and that’s it.

The line Identity let’s you specify users or groups that the policy impacts.
The items are ; separated and each one must start with unix-user or unix-group
and have a user, group or wildcard following it.

Now, if you want to test to make sure this works you can, of course, run the
program in question. OR you can use pkcheck.

you use pkcheck like this:
pkcheck –action-id org.freedesktop.packagekit.package-install \
–process $process_id_of_the_process_making_the_request \
-u $the_username_you_are_testing

the process id I used was of a shell of the user or was the gnome-session process.

it should pop up an auth dialog if you did everything correctly.

For more complete docs look at:
man pklocalauthority

and

man polkit

hope this helps.

[Dies]

Originally Posted by kyryder

In f12 the default policy for polkit for package kit is to allow users at the
desktop to install signed pkgs from repositories enabled on the system.

Huh, wasn't like that when I installed this system, but then again it's not an actual release so... I'll install the actual release later and check it out.

Thanks for finding and sharing the info though.

Originally Posted by Dies

Thanks for finding and sharing the info though.

Even a blind squirrel gets a nut every once in a while.

[kevlar]

So Polkit is a suid root daemon that grants permissions.

It has pkaction which gives undescriptive names of what polkit can do but according to this thread that doesn't even inform you of what is allowed to Run. The documentation doesn't help here at all either. etc. certainly does not belong in the scarce permissions descriptions.

You can edit config files to turn off or control these permissions. However on f17 there are no config files so you would expect no permissions enabled. Wrong.

Good security requires transparency. Anyone else see the fundamental flaw, never mind configuration idiocy here. Are we expected to track the source and work out each permission ourselves!!!


Systemd takes longer to use on the commandline and I prefer shell scripts in one location but atleast it brings some benefits that can't be done with other better tools and atleast you don't have to write an essay to turn some things off.

p.s. almost no proper admin likes XML. There is NOTHING wrong with tried and tested traditional UNIX textual config files except perhaps in a realtime system requiring binary, which is very rare!!!

p.p.s. Getting gnome3 to not raise a window on click seems impossible, getting it to not raise a window on focus is do-able but another config system mess.

And someone tried to tell me I should use Fedora, walking off in a knowing fashion, what a cheek. Fedora has some merits but fedup is certainly more appropriate in other ways.

[smr54]

Note that this thread is close to three years old.

There is a rants section of the forum--it's original purpose was to allow people to vent, but unfortunately, when they do, the fanboys come in and tell them how stupid they are.

Also note that developers don't often see these threads--while a few sometimes look through the forum, generally, the best way to reach them is by filing a bug report. However, I think you (us) have to accept that for better or worse, Fedora's target audience seems to be, more and more, the desktop user, and with each release, it becomes harder and harder to deal with it as a sysadmin. I suppose Debian admins probably feel the same way about each new Ubuntu release.

Edit: The above was written late last night--in morning's light, I am sure that part of my irritation is simply that of anyone forced to learn something new when they're lazy. Some of these things will, if not now, later, be improvements, and some, no doubt, will drastically contradict the old adage that Unix doesn't keep you from doing stupid things because that would keep you from doing clever things. One forum member has compared some decisions to the being similar to welding on training wheels.

Anyway, main points to be gleaned from my ramblings are that this thread is quite old, there is a rants forum, but usually the ranter is criticized, and, that at least in my admittedly old person's opinion, Fedora is, more and more, aimed primarily at the desktop user, and, judging from its popularity, seems to be what the majority want.