[PATCH] Apply ACLs even if acl list reading failed

Lubomir Kundrak lkundrak at redhat.com
Thu Mar 6 12:29:13 PST 2008


On Thu, 2008-03-06 at 20:56 +0100, Danny Kukawka wrote:
> On Donnerstag, 6. März 2008, Lubomir Kundrak wrote:
> > On Thu, 2008-03-06 at 19:50 +0100, Danny Kukawka wrote:
> > > On Mittwoch, 5. März 2008, Lubomir Kundrak wrote:
> > > > List of applied ACLs can get corrupted, and that prevents hal-acl-tool
> > > > from ever touching it again and fixing. Trivial fix attached.
> > > >
> > > > If that was due to a crash, etc, it is not valid any longer anyways. In
> > > > that case probably it would make sense to relocate
> > > > /var/lib/hal/acl-list into /var/run/hal, and let it be removed by
> > > > operating system startup scripts.
> > >
> > > If you say the change is okay from the security POV, I commited it.
> >
> > That had nothing to do with security. Problem was that I have seen a
> > report, that user's acl list got somehow corrupted (probably due to a
> > system crash or power outage or whatever). The run-specific data should
> > really not survive reboots -- in this case it prevented from hal ever
> > being able to parse the acl list again, though its contents were not
> > pertinent to current run.
> 
> Sorry, wasn't clear enough. I fully understand why you moved it 
> to /var/run/hal, but I wasn't totally sure about the first small patch.

That meant to address the same problem in a different way -- if
hal-acl-tool detects the acl-list is corrupted and can't read acls,
apply the new acl set anyway. Again, to be clear, really nothing to do
with security; if user's acl list get corrupted during the run we might
not revoke the acls properly and there's no way to avoid it. That user
would have bigger problems anyway :) This would just make the acl-list
syntactically correct, so that future hal-acl-tool runs won't panic.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



More information about the hal mailing list