PolicyKit auditing - was Fedora 11: moving to posix file capabilities?
On Wed, Oct 29, 2008 at 5:04 PM, Steve Grubb <firstname.lastname@example.org> wrote:
> On Wednesday 29 October 2008 16:52:48 Colin Walters wrote:
>> > Not sure I follow your question. I am talking about /proc/<pid>/loginuid
>> > and sessionid.
>> Oh. Well, if your application uses PolicyKit there are *two*
>> programs; the privileged mechanism, and the unprivileged application.
>> The unprivileged application of course maintains the loginuid.
> Which is a problem. We have no way to connect the session ID for the backend
> with the frontend. That means we can't make a killall mechanism that nails
> everything in a login session.
Conceptually the mechanism isn't part of the login session, it's OS
infrastructure that runs in userspace, just like libvirtd, iscsid
or HAL. In particular the same mechanism process can be reused by
multiple uids, just as multiple uids can share a page cache entry in
the kernel or enumerate devices from the HAL daemon.
> No...we have a handful of apps that audit changes to trusted databases.
> password and adduser are two examples.
Sure...but that's a tiny minority of files for the core OS; at least
looking at "ls /etc". Don't get me wrong, I think it would make sense
to have a frontend tool but I can't see how the lack of one would be
considered a blocker.
> I have to be able to tell the audit system to include or exclude events from
> certain users. That would mean a user space access control daemon would have
> to download and enforce audit policy. Nothing else does that because all the
> necessary process attributes are maintained across the exec model and the
> kernel can access it all.
How Policykit should interact with auditing sounds like something to
bring up on the PolicyKit list; like I said before I think we do want
at least auditing of dbus system activation and that would be a use
case for userspace audit policy loading.
 Why the heck is my F9 desktop running iscsid?
fedora-devel-list mailing list