On over-engineering

I’ve been trying to get a udev rule added to Ubuntu so that /dev/infiniband/rdma_cm is owned by group “rdma” instead of by root, so that unprivileged user applications can be given permission to use it by adding the user to the group rdma.  This matches the practice in the Debian udev rules and is a simple way to allow unprivileged use of RDMA while still giving the administrator some control over who exactly uses it.

I created a patch to the Ubuntu librdmacm package containing the appropriate rule and opened a Launchpad bug report requesting that it be applied.  After two months of waiting, I got a response that basically said, “no, we don’t want to do that.”  After another month of asking, I finally found out what solution Ubuntu would rather have:

Access to system devices is provided through the HAL or DeviceKit interface. Permission to access is managed through the PolicyKit layer, where the D-Bus system bus service providing the device access negotiates privilege with the application requesting it.

Because of course, rather than having an application simply open a special device node, mediated by standard Unix permissions, we’d rather have to run a daemon (bonus points for using DBus activation, I guess) and have applications ask that daemon to open the node for them.  More work to implement, harder to administer, less reliable for users — everyone wins!


8 Responses to “On over-engineering”

  1. jh says:

    and that’s why you never use a OS built by children. there are much more sane distro’s that do the right thing rather than the trendy.

  2. Tomasz says:

    First, it’s typical experience with Ubuntu bugs… month of waiting for useless answer.

    For the second. Well welcome to the future. PolicyKit with hal (to be replace with DeviceKit) is the new way, pushed by major distributions, of managing permissions. But now it’s generally used for multiuser desktop (along with ConsoleKit tracking active users), not for servers with remote logins, where group-based permissions should be used. Good luck with explaining that in launchpad. I bet you won’t have it resolved thsi year.

  3. Anonymous says:

    just add something to /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi

    if Ubuntu uses that.

    For Fedora that file can be made set the perms for each logged in user and also does the right thing on fast user switch.

  4. roland says:

    @jh: yes, the end result is that I give up on fixing this for Ubuntu. Debian and others have the right group permissions in their udev rules already, and I don’t have the energy to fight anyone who doesn’t want me to help.

    @Tomasz/@Anonymous: being morbidly curious I did lshal on a system with the rdma_ucm module loaded (so the /dev/infiniband/rdma_cm node existed). And I don’t see anything in the output that looks related to rdma_cm. So specifying permissions with hal/PolicyKit is going to be a lot of “fun.”

    And the whole ConsoleKit/PolicyKit/hal thing is just stupid anyway for systems where users log in remotely (or submit batch jobs through a queuing system), as you point out.

  5. Nate says:

    Ya. That seems a bit backwards from my understanding of the purpose behind policykit and such.

    The idea I have is that you have some daemons that are operating under different privileges from end users and then you have policykit setup as a way to manage permissions of users interacting with those daemons via dbus IPC.

    This way you can hide a big hunk of code running with extra permissions behind a audited dbus interface, eliminate the need for end users to be granted extra permissions that they only need for certain tasks, and make it easy for administrators to manage those permissions through standard interface.

    So if your users have a specific task, and you want to take advantage of policykit, then you create a daemon to perform that task on their behalf and have those users communicate with that daemon through dbus.

    Now if you want to allow a certain class of users general use of certain files or devices then going through policykit to manage file system permissions is a bit perverse.

  6. Dan Nicholson says:

    I don’t see why both ways can’t be used. For a desktop user who is only going to use gui tools to access the device, then having HAL and PolicyKit manage the interaction is probably a smart way to go since it can handle much finer grained permissions like knowing whether the accessing user is in an active session or not.

    But certainly every tool is not going to grow PolicyKit integration, so setting reasonable Unix ACLs seems wise. After all, this is already how most devices are handled, like CDs and USB devices. Saying that RDMA access is either root or via PolicyKit just denies a class of users for no apparent reason.

  7. Adam G says:

    I blame idiots doing bug triage. If you can get the attention of someone who actually does work (not the copy and paste brigade), they’ll probably agree to the sensible thing you propose.