Managing ACL's on device nodes
david at fubar.dk
Tue Feb 6 20:32:07 PST 2007
On Tue, 2007-02-06 at 23:10 -0500, Bill Nottingham wrote:
> Since it's granting device access, this puts hald in the security path -
> it's something that can't fall over, or devices won't get reset on logout.
We're already there with mounting / unmounting but yes. For storage
devices we keep a state file in /media/.hal-mtab and upon hal startup
changes will be undone (cleaning up /media).
(We can do a bit better now with ConsoleKit btw, we can unmount devices
from the user when he logs out.)
So for this I envision that hal will maintain a state file of ACL's
granted somewhere in /var/run/hald, say /var/run/hal/acls_granted. On
startup of hal we process this file and removes the ACL's previously
added (want to be careful not to remove ACL's not granted by HAL).
Obviously hald should be respawned if it crashes and I think that will
take care of it (probably using Upstart will make that easier). At the
very least, with SysV init, we do something else, e.g. just run the
clean-up program to remove the ACL's granted when we see that hald
> Obviously, we want it to be bulletproof anyway, but it's worth mentioning.
> What's the behavior if ConsoleKit goes AWOL,
Good point. Then we revoke ACL's previously granted using the same
mechanism as above.
> for whatever reason, or if
> GDM/the X session crashes?
Then ConsoleKit will notice.. this is because GDM keeps a connection to
the system bus and the bus will tell ConsoleKit when it goes away.
> How are seats named/described (re: info.access.seats)? (Yeah, I should
> probably just read the ConsoleKit docs.)
Executive summary: they're just D-Bus object paths. I don't think we'll
be doing stuff for multi seat initially though.
> It looks like we're going to need to extend this if we want it to work on
> the virtual console.
Not really. You just teach the login manager like GDM to keep a
connection open to ConsoleKit. In that case it's login(1). I don't think
virtual consoles are interesting but that's another discussion :-)
> We don't (unless I'm mistaken) have revoke(); without this, ACLs aren't
> bullletproof (but neither is chown). Of course, once we get revoke(),
> apps will probably break. :)
Sure, it's just a modern pam_console replacement if you like. When we
get revoke() it's relatively easy to break the apps and then someone
will get to fix them.
> It's moving the changing of device ownership from a (relatively)
> synchronous process (pam_console) to an asynchronous one; not that that's
> necessarily *bad*, but it's different.
Sure; you make some good points and I hope the implementation details I
gave above will convince you this can be done in a bullet proof way.
> I suppose what it boils down to is that this gives you the ability to
> only have devices with the active session, or to tie devices to a particular
> seat - the other models you propose could be done with pam_console
> or similar.
Sure... one main point, however, is to have some system that isn't
distro specific. And pam_console is just way to low in the stack to do
things like cleaning up after the user (e.g. unmounting storage devices,
revoking ACL's on device nodes).
More information about the hal