6 ms·

The only things on my system that depend on it are pipewire and xorg-x11-drv-intel (which I don't need). It doesn't sound like you should need a GUI sudo with

The only things on my system that depend on it are pipewire and xorg-x11-drv-intel (which I don't need). It doesn't sound like you should need a GUI sudo with XML and Javascript for audio..

0xbadcafebee 5y ago
It does appear to exist solely to let users use their own local hardware: https://wiki.debian.org/PolicyKit https://wiki.debian.org/PolicyKit PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes, in order to grant some user the right to perform some tasks in some situations. It is sometimes referred to as "the sudo of systemd". Sample uses: Let the user Hibernate and shutdown the computer. Let the user manage (Wireless) connections. Let the user mount/eject a removable media (CD/DVD, USB keys...) Let the user access devices, like audio, scanner, etc. We already had a solution for this before: you add the user to the 'audio' group. And SELinux could do this too. But apparently RedHat just wanted another layer (https://lwn.net/Articles/258592/ https://lwn.net/Articles/258592/). "This is better than groups and setgid processes, because it means someone can't log in over ssh and mess with another user at the console." - Because that's what desktop users are really concerned about. We need more complexity because somebody might hax0r my desktop over SSH. And, wow, they really actually did use XML as their configuration: <match action="org.freedesktop.hal.storage.mount-fixed"> <match user="davidz"> <return result="yes"/> </match> <match user="freddy"> <return result="no"/> </match> </match> So, not only is it superfluous, it also doesn't make the user's life easier, it's super annoying to configure, everything depends on it, and now the thing intended to improve security has caused a security issue.
- throwawaysysd 5y ago
  Creating another group every time and asking the sysadmin to add you to the group when you want a new permission is not an appropriate solution for the desktop. It also isn't fine grained (what if you want to only grant permission to one audio device, then you'll need to create lots of audio groups and keep track of them all) and doesn't handle the case where you want to temporarily grant privileges to some device for just one session. There is more to it than just the issue with ssh, and it's not superfluous. There is a very good reason desktops all use it.
  - throwaway984393 5y ago
    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?
    - throwawaysysd 5y ago
      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.
      - michaelmrose 5y ago
        > As the sysadmin you can configure some actions to always accept or always deny, if you want You can do this with sudo too.
        throwawaysysd 5y ago
        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.
- yrro 5y ago
  If you add your users to the 'audio' group then they can SSH into machines to eavesdrop. $ getfacl -p /dev/snd/pcmC0D0c # file: /dev/snd/pcmC0D0c # owner: root # group: audio user::rw- user:sam:rw- group::rw- mask::rw- other::--- On my systems, the 'audio' group is empty. The ACL of the audio device (and other devices with the `uaccess` tag) is adjusted by udev when the owner of the active console session changes. (I don't know if the scheme is able to revoke access to a running process, but it's still a step up from a single, static 'audio' group).
  - 0xbadcafebee 5y ago
    How many Linux users really expect a hacker to 1) be on their local network, 2) find a zero-day exploit in SSH, and 3) want to eavesdrop on them? I'm pretty sure I'd get struck by lightning while attacked by a shark before that ever happened
    - foxfluff 5y ago
      I feel like this whole thing is driven by corporate interests. It would make sense in a context where a machine has multiple users (or: anyone at work can use their credentials on any workstation), which is not uncommon in a work environment. It seems largely irrelevant for a single-user desktop. It irritates me that the Linux environment is constantly growing more complex to account for scenarios that are not relevant for me, and it's hard to opt out. That complexity is not zero-cost; I've been hit by many a bug (and have wasted a lot of time working around..) related to things that exist on my system yet serve no real purpose for me. I guess it's the year of the Linux desktop when it gets corporate enough, and those who want a comfortable free operating system will be looking for alternatives :)
    - yrro 5y ago
      I have personal experience of this happening in lab environments. And there's no SSH exploit necessary. I'm not talking about a hacker from the internet, I'm talking about a malicious co-worker. The old permission model of "just add everyone to the audio group" is not sufficient.

The only things on my system that depend on it are pipewire and xorg-x11-drv-intel (which I don't need). It doesn't sound like you should need a GUI sudo with XML and Javascript for audio..

0xbadcafebee 5y ago

It does appear to exist solely to let users use their own local hardware: https://wiki.debian.org/PolicyKit https://wiki.debian.org/PolicyKit PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes, in order to grant some user the right to perform some tasks in some situations. It is sometimes referred to as "the sudo of systemd". Sample uses: Let the user Hibernate and shutdown the computer. Let the user manage (Wireless) connections. Let the user mount/eject a removable media (CD/DVD, USB keys...) Let the user access devices, like audio, scanner, etc. We already had a solution for this before: you add the user to the 'audio' group. And SELinux could do this too. But apparently RedHat just wanted another layer (https://lwn.net/Articles/258592/ https://lwn.net/Articles/258592/). "This is better than groups and setgid processes, because it means someone can't log in over ssh and mess with another user at the console." - Because that's what desktop users are really concerned about. We need more complexity because somebody might hax0r my desktop over SSH. And, wow, they really actually did use XML as their configuration: <match action="org.freedesktop.hal.storage.mount-fixed"> <match user="davidz"> <return result="yes"/> </match> <match user="freddy"> <return result="no"/> </match> </match> So, not only is it superfluous, it also doesn't make the user's life easier, it's super annoying to configure, everything depends on it, and now the thing intended to improve security has caused a security issue.

throwawaysysd 5y ago
Creating another group every time and asking the sysadmin to add you to the group when you want a new permission is not an appropriate solution for the desktop. It also isn't fine grained (what if you want to only grant permission to one audio device, then you'll need to create lots of audio groups and keep track of them all) and doesn't handle the case where you want to temporarily grant privileges to some device for just one session. There is more to it than just the issue with ssh, and it's not superfluous. There is a very good reason desktops all use it.
- throwaway984393 5y ago
  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?
  - throwawaysysd 5y ago
    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.
    - michaelmrose 5y ago
      > As the sysadmin you can configure some actions to always accept or always deny, if you want You can do this with sudo too.
      - throwawaysysd 5y ago
        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.
yrro 5y ago
If you add your users to the 'audio' group then they can SSH into machines to eavesdrop. $ getfacl -p /dev/snd/pcmC0D0c # file: /dev/snd/pcmC0D0c # owner: root # group: audio user::rw- user:sam:rw- group::rw- mask::rw- other::--- On my systems, the 'audio' group is empty. The ACL of the audio device (and other devices with the `uaccess` tag) is adjusted by udev when the owner of the active console session changes. (I don't know if the scheme is able to revoke access to a running process, but it's still a step up from a single, static 'audio' group).
- 0xbadcafebee 5y ago
  How many Linux users really expect a hacker to 1) be on their local network, 2) find a zero-day exploit in SSH, and 3) want to eavesdrop on them? I'm pretty sure I'd get struck by lightning while attacked by a shark before that ever happened
  - foxfluff 5y ago
    I feel like this whole thing is driven by corporate interests. It would make sense in a context where a machine has multiple users (or: anyone at work can use their credentials on any workstation), which is not uncommon in a work environment. It seems largely irrelevant for a single-user desktop. It irritates me that the Linux environment is constantly growing more complex to account for scenarios that are not relevant for me, and it's hard to opt out. That complexity is not zero-cost; I've been hit by many a bug (and have wasted a lot of time working around..) related to things that exist on my system yet serve no real purpose for me. I guess it's the year of the Linux desktop when it gets corporate enough, and those who want a comfortable free operating system will be looking for alternatives :)
  - yrro 5y ago
    I have personal experience of this happening in lab environments. And there's no SSH exploit necessary. I'm not talking about a hacker from the internet, I'm talking about a malicious co-worker. The old permission model of "just add everyone to the audio group" is not sufficient.