On Tue, 2009-11-24 at 13:18 -0500, Matthew Miller wrote:
> Like I said, this is a tangent, and I'm certainly not expecting anyone to
> work on this. But it'd be cool if they did.
Just as everybody else is struggling to get away from pam's awful
apis...I don't think this would be a step forward; b
On Tue, 2009-11-24 at 12:29 -0500, Matthew Miller wrote:
> 1. In fact, a PAM-backed authority for PolicyKit might be interesting and
> useful -- but there's a tangent.
What do you think PolicyKit is using for authentication ?
See
http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polki
On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote:
> >
>
> when the policies are updated it is policy kit that has to be involved.
> polkitd is running, at least.
That might be ok to log, indeed. polkitd need not be running, though. It
is activated as needed.
> It would make sense for polkit
On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote:
> One of the important features of sudo is its ability to log elevated-access
> actions to syslog.
>
> Userhelper similarly logs actions, like so: "userhelper[26491]: running
> '/usr/share/system-config-users/system-config-users ' with root
On Mon, 2009-11-23 at 19:36 -0500, Seth Vidal wrote:
>
> On Mon, 23 Nov 2009, Matthias Clasen wrote:
>
> > On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
> >
> >> Otherwise we open ourselves up to a less-secure-by-default posture in an
> >> averag
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
> Otherwise we open ourselves up to a less-secure-by-default posture in an
> average install.
>
> We've been in that position in the past and it is not a favorable place to
> be.
>
We should just avoid to sink tons of QA resources in verify
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
> It's not QA's role to define exactly what the security policy should
> look like or what it should cover, but from the point of view of
> testing, what we really need are concrete requirements. The policy does
> not have to be immediately
