Managing ACL's on device nodes

[David Zeuthen]

Hey,

Now that we've got ConsoleKit integrated into HAL (optionally of
course), I thought it would be a good time to teach HAL about managing
permissions on device files. 

Today, managing device file permissions is pretty much done on an ad-hoc
basis depending on what distribution / operating system you are running
and most distros don't use ACL's in the default install. This is a
headache for some people, see for example

 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853

There are also various opposing philosophies about how to do this
"Right"; there's the Debian school of thought saying something along the
lines of "you need to be in a specific group to use a specific class of
device (e.g. audio, plugdev etc.) [1]" and there's the Red Hat, and now
SUSE, way allowing users on the system to use a device if, and only if,
they are at the system console [2].

With asynchronous notifications from ConsoleKit about seats coming and
going and sessions becoming active / inactive there's a lot of room for
improvement too; it's not far fetched that one wants to allow a user
access to a device if, and only if, they are in an active session on a
system console.

So here's a proposal for something I want to add to HAL to address this.
It would, of course, be an optional feature

 1. Introduce the following properties 

  - info.access.seats (strlist)
      This is a list of seats to which a device belong to; if it's empty
      it means that the device is available for all seats (this will be
      the default)

  - info.access.grant_local_session (boolean)
      Access will be granted to all users logged into a seat regardless
      of whether the session is active or not

  - info.access.grant_local_active_session (boolean)
      Access will be gratned to all users logged into a seat but only
      when the session is active

  - info.access.grant_user (strlist)
      Strlist of users to always grant access to

  - info.access.grant_group (strlist)
      Strlist of groups to always grant access to

 2. Write some code in the main hal daemon to call out to setfacl(1),
    via our runner, as appropriate to maintain the ACL's when users
    login / logout and sessions become active / inactive (we get all
    this via ConsoleKit) and when devices are added.

    Performance-wise it shouldn't be too bad, there's not a whole bunch
    of device files we want to put ACL's on (only sound cards, optical
    drives, webcams, digital cameras, scanners comes to mind).

    We'd write .fdi files to define what classes of devices to do this
    for; distros can fine tune this to match their policy, e.g. Debian
    would utilize info.access.grant_group and RH / SUSE systems would
    use info.access.grant_local_session as well as, perhaps,
    info.access.grant_local_active_session.

    Software like Flumotion, as referenced in the RH bug above, would
    simple drop an fdi file that appends 'flumution' to the property
    info.access.grant_user on webcams and sound cards and, hey presto,
    they can ship this in their upstream tarball and life is simpler
    for packagers.

    If I'm an IHV/ISV with a closed source app using a user space
    driver I can now simply ship an .fdi file that sets the property
    info.access.grant_local_session on the USB devices that my app
    can drive. Things like scanner apps etc. comes to mind (my
    colleague Dan Berrange had this problem some time ago). This
    would work on any distro with a recently new HAL and this option
    turned on.

 3. What about udev? It's true that udev provides some support for
    setting owner:group on a device file and it should probably stay
    that way for core configuration; e.g. this is where you want to
    set root:disk for disk drives etc. Apart from that we should
    recommend that people, packagers in particular, stop using udev
    rules to change device file owner ship. Kay?

Thanks for considering. I'm probably going to start hacking on this
tomorrow morning EST but I thought it would be good to ask for opinions
etc. before.

     David

[1] : and if you are a member of the group at some point you can always
become a member again, e.g. "Log in, added to group, copy shell, add
setgid bit..."

[2] : By "system console" I mean a monitor + keyboard/mouse attached to
the local system