Bug 497621

Created attachment 343665 [details]
new patch

Ok, the first patch doesn't work, polkit 1 does not support checking for a _users_ privileges like that. Therefore, and since PAs use of polkit seems a bit misguided, anyway, I've instead written a patch that just removes polkit support.

> Ok, the first patch doesn't work, polkit 1 does not support checking for a
> _users_ privileges like that. Therefore, and since PAs use of polkit seems a
> bit misguided, anyway, I've instead written a patch that just removes polkit
> support.  

Misguided, how so?

I haven't looked into pk 2, but I thought I discussed with davidz back then that the PA use case does make sense. i.e. instead of having the privilige seperation by having one priviliged and one unprivilige process at the same time seperated by the process boundary we have the prviliged and unpriviliged code in the same process, seperated by time and the fact that we drop priviliges.

Matthias, I have now discussed this with David on IRC.

While David seems not to agree that PA using PK for this is the right approach I really see no better way. 

The longer story is like this: PA works much better if it is an RT process, which is controlled via the CAP_SYS_NICE capability. Right now being an RT process on Linux allows you to freeze your machine indefinitely. Since PA allows loading of user modules during runtime (and relies on it for hotplug and so on), the user could hence create his own code that uses CAP_SYS_NICE to freeze the machine.

Even if one day Linux is fixed that normal user processes may be RT without getting the ability to freeze the machine forever, RT scheduling still comes at the price that the process can block the machine for a short time (some timeout of 2s or so). It will generally influence the normal process scheduling in very strong ways. On multi-user systems that may be too much. So, regardless if this is fixed or not in Linux, the admin *needs* to be able to authorize usage of RT scheduling individually for each user. Fixing the kernel will allow us to set the authorization for RT to 'true' by default, but even then we will need to retain the ability that admins may set it to 'false' if they wish.

Now, the authorization logic for this doesn't have to be implemented via PK. In fact PA also supports auth for this via unix group membership. I guess we all agree that this is worse than using PK. An alternative would be to control this via an explicit configuration file that is under the sole control of root. But I cannot see what the advantage over PK would be here. The whole point of PK was to centralize authorization, even across the network. If I split this into a seperate config file all this is lost. Also, I really don't see why this kind of authorization should be outside of PKs field.

Anyway, David said that PA may use PK by talking to it via D-Bus directly. I will cook up a patch for that after the new PK entered Rawhide.

I'm always happy to listen. So if anyone can explain to me convincingly how else I should be handling the whole RT situation then I am open for everything. But otherwise, using PK for this seems to be the natural choice to me, and a patch that just rips the whole logic out is no solution.

I guess the basic hangup is that if rt is required to make pa work, then it needs to use rt. Any switch to turn that off (globally or for individual users) is just a 'break Davids sound experience' toggle, then. 

Anyway, not a big deal. If you write a patch to make pa work with polkit1, I'll happily continue to ignore this issue.

A little update:

I have now prepared this little kernel patch:

http://lkml.org/lkml/2009/5/28/257

If that gets merged then we'll be able to have a little daemon that hands out RT to user processes that ask for it, securely and without the ability that the RT scheduling could "leak" to child processes or RLIMIT_RTTIME be circumvented.

With that in place we shuld be able to enable RT by default without any further security headaches.

As a side effect this allows us to strip suid root and auth from PA. Auth will be moved into that little RT daemon.

In effect all issues we have right now should be solved: we can enable RT by default, polkit can be dropped from PA, but RT is still authenticated via polkit, but in a way that is more like the texbook, i.e. davidz should be happy.

And everyone can rejoice.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

PA in Rawhide does not use PolicyKit anymore.