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.

Even though the situation described is strange to the point of having never happened in history you would still need to ask an admin to write policy to implement your interesting audio permission scheme just the same as one would need to ask an admin to add a group or you know automate the process with a gui or integrate the change in groups into updating or software installation.

I am sure that somewhere having an actual programming language available vs list of what can and can't be run with or without a password would enable some additional power in terms of control of the system but I cannot for the life of me imagine a situation where it would be all that useful.

I agree it's not particularly useful for home users, I expect most would go with the defaults provided by their distro and leave it there. This is meant for corporate deployments where sysadmins might need to write more advanced policies.

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?

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.

> There is a very good reason desktops all use it.

FSVO "all". Mine doesn't use it. If I have a task that needs elevated privileges, I run it from a terminal. Seems to work for me.

Sorry but if you keep falling back to the terminal to do things I would say you're not really using a desktop. What's the purpose of pointing this out? Yes, you can do whatever you want in Linux by opening the terminal and typing sudo. I understand the propensity of developers to like this because we spend all day in our xterm windows anyway but this is not the way anyone else expects a desktop to work.

Just to follow this discussion a bit further: If you have a task that /really/ needs elevated privileges you could turn it into a kernel module. That's great for you if you want to do that, but will you tell everyone else to develop kernel modules for every little thing? I don't think I would. I'm happy to give the muggles a better interface.

I have no "desktop" tasks that need elevated privileges. I only use a GUI because I want to run things like a browser and a media player. If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.

There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.

A lot of the Linux desktop effort seems to really be "Linux laptop" - Linux support for machines that are constantly moving from one hotspot to another, and constantly having storage and other devices plugged in and unplugged. That isn't my use-case. Most of my Linux machines are servers with no GUI. The one with a GUI doesn't travel, and gets something plugged into it maybe once a month.

I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.

> There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS.

And not necessarily with the interests of Windows or MacOS end users, but more corporate interests.

I think a lot of Windows users for example were and would still be fine with a system that is effectively a single-user desktop. A permission prompt to prevent random apps from spying on you using your microphone and camera is probably a Good Idea for the average user but all this user policy business is just pointless; users themselves should always have access to their own devices anyway, just as they would on old Windows installs where the user was typically the only user and always administrator.

And yeah, I don't like that a few people get to define what exactly constitutes a desktop for everyone. Especially if under the guise of "this is what a modern desktop requires" they're free to turn the platform into a bloated, overcomplicated mess.. exactly the kind of thing I was happy to get away from when I left proprietary operating systems behind two decades ago.

I don't understand what you mean by a few people get to define it. This stuff is used by basically every desktop environment on Linux. You have to either use it or write something very similar to it if you want to have permission prompts that actually work. They all give the option to turn it off but they still have to support it for the average user you described. Unsurprisingly, the requirements for shipping a desktop are really not that different on Linux compared to other operating systems. The users all want the same things.

From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people. You can find distros that still ship a desktop from that era but they don't seem to be for much beyond novelty.

> if you want to have permission prompts

Why would I want permission prompts? Most systems are single-user systems; if you're logged in, you're the administrator, even if you haven't yet invoked your superpowers. Arguambly you should have to confirm if you want to do something dodgy; but if all you have to do is say "Yes, thanks for the warning", then you don't need any kits.

Really, I have difficulty imagining this group of Linux users who are constantly hot-laptoping, so that they need multi-user support sprinkled all over the OS. I can see that it's useful in a pair-programming environment, where you might have a lab or workstations with a standard config; but apart from that, how often does someone else log in to a desktop/laptop computer you normally use? Or one you own?

I don't think hotdesking and hotplugging are urgent consumer requirements. I don't think the people producing this stuff are aiming it at consumers.

> or write something very similar to it

Or use what was written before, if it matches your use-case. That worked, for many people. Still does for some.

> The users all want the same things.

Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.

> From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people.

I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop. It's irrelevant whether dave and samantha can access the audio device in john's session because dave and samantha don't exist on john's personal computer and he sure ain't running an ssh daemon for them.

>Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.

I'm not speaking of corporations here, this is basically every current desktop environment that is shipping on Linux right now. They are all either using polkit or they use something very similar to it because the idea of it (user asks to perform an action, show a prompt) is very straightforward and pretty much universal for GUIs by now. Some of them may be business-oriented but some aren't. If this doesn't fit the definition of "everyone" using desktop Linux then who else are you considering? And just to clarify, I would say using sudo with a fine-grained config is roughly equivalent to polkit, although less convenient for GUI users because it doesn't have pluggable authentication agents.

>I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop.

This itself is a strawman though. Polkit and sudo and such are not strictly about user policies although you can use them for that.

>If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.

This is why polkit actions are the way they are, so you actually have a chance of being able to encode those one-off tasks into permissions for a GUI. It's not implemented for everything that requires root, and it probably won't ever be implemented for all of it but it's a lot better than it used to be. Part of it is improving because desktops like KDE made it easier to plug in new panels to the system settings, another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc) instead of trying to access the raw devices themselves.

>There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.

I don't disagree with the last part here but, companies like Canonical exist and they get paid to ship this stuff. There are customers out there who want this, and they may very well be the ones paying some money or contributing maintenance towards keeping your browser and media player working on Linux. I don't know any overarching reason why these customers would deploy Linux instead of Windows, you would have to ask them.

>I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.

Sorry but I don't think any usage of the terminal is a counterexample. That's just sidestepping the desktop, you could also do that from a VT with no GUI present.

> another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc)

Not the applications that I use! The machine in question doesn't have dbus or systemd. It only has one user. That layer of complexity is of zero value to me, but it's the very devil to get rid of it all.

> Sorry but I don't think any usage of the terminal is a counterexample.

If, on Windows, you have to perform a task for which there is no pre-made GUI app you can install, then you have to run-up powershell or cmd. My case is identical. I specifically referred to one-off tasks.

It's not my use of terminals that is the counterexample; it's the fact that I run a desktop without polkit (or anything-kit).

On Windows, if there has been value in putting those tasks in a GUI in the control panel, they will do it. It's the same deal.

Yes you can technically build a system without dbus or systemd or polkit or gettext or the C library or whatever it is you feel is superfluous. As you've found it is not actually difficult to do that, just tedious and impractical. You aren't gaining anything here by removing things. If you want equivalent functionality you're now tasked with building the equivalents, e.g. Android which is also a single user userspace for Linux without dbus or systemd, but has its own fairly complex set of high level services and IPC system.

> As you've found it is not actually difficult to do that, just tedious and impractical.

That is the opposite of what I have found; I find that it's "the very devil" to remove these components. And my finding is that the presence of these components is tedious and impractical, and that their absence makes my life better.

> You aren't gaining anything here by removing things.

That is condescending.

I've used machines with these services and I've used machines without. I find it's a gain to not have them. Who are you to tell me whether I do or don't gain anything?

FTR I don't have to build anything; there are alternatives, which I use. Unfortunately these new components are more-or-less rivetted-in, which makes it hard to remove them and replace them. Screws are better than rivets.

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

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

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 :)

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.