Comments on: On over-engineering

By: roland

roland — Thu, 25 Dec 2008 15:25:08 +0000

@Adam: Sadly, not in this case. Look at the bug I link to and check out who the replies are coming from.

By: Adam G

Adam G — Thu, 25 Dec 2008 02:46:59 +0000

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.

By: Dan Nicholson

Dan Nicholson — Thu, 20 Nov 2008 20:43:54 +0000

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.

By: Nate

Nate — Thu, 20 Nov 2008 05:17:29 +0000

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.

By: roland

roland — Wed, 19 Nov 2008 23:25:02 +0000

@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.

By: Anonymous

Anonymous — Wed, 19 Nov 2008 22:57:50 +0000

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.

By: Tomasz

Tomasz — Wed, 19 Nov 2008 19:21:33 +0000

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.

By: jh

jh — Wed, 19 Nov 2008 18:49:09 +0000

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.