Hacker News Reader

Comment by throwaway984393 | Hacker News Reader

What sysadmin are desktop users having to ask for permission to use their own hardware? Even in 2001, if you had a laptop, you had access to use all it's hardware. Why wouldn't you?

How many groups do you think there are? There's only so many classes of hardware, so there's only so many groups. About 8 in total. You add the user to all of them at once. It worked just fine before polkit arrived.

Why would you want to temporarily grant privileges to hardware once? Who is trying to prevent the user from using their own hardware?

What's the very good reason all desktops use it?

View on HN

I detailed this in another comment, the reason desktops use it is to get those macOS-style permission dialogs that pop up when you try to take some privileged action. I don't think any desktop distribution wants to ask users to open a terminal and type "sudo usermod" and then log out and log back in in order to do something like setting the clock or formatting a usb drive. I don't remember this working well at all before polkit arrived either, I remember when device hotplug in Linux was really broken for this reason (and a few others). It's not reasonable to ask desktop users to edit udev rules when plugging in a new device. If it worked well at all it was because you were doing things like having a lot of suid/sgid tools or just running GUI programs as root which is a terrible idea.

>Who is trying to prevent the user from using their own hardware?

I don't understand this question. The functionality here is equivalent to sudo, you type your password to authenticate a certain action. As the sysadmin you can configure some actions to always accept or always deny, if you want.

> As the sysadmin you can configure some actions to always accept or always deny, if you want

You can do this with sudo too.

Yes, polkit does have some overlap with sudo. What it has over sudo is a real API, programs can use it to authenticate an IPC request for an action to a privileged daemon while that daemon is running.

Why isn't the audio device owned by the logged in user? udev could easily do that.

It'd be a problem if more than one user in logged in to the local console, in a multi head environment for example. But those are rare, and already have to solve the same problem for other console related devices such as mice and keyboard.

Reply on news.ycombinator.com