Seems reasonable to me, that users who can add packages without additional authentication, should be able to remove those packages. What's the contrary argument?

I put adding/removing printers in this same category was well, a user in wheel should be able to handle this without authentication.

I'm struggling to parse this issue: what's the short issue summary, and what's being proposed as the fix?

It's worth being clear about what the use cases are here. Single user system is the main case and a key one to focus on. For multi-user I generally limit it to small home installations, where you have a small number of people with a relatively high degree of trust. Child accounts are a slightly special case for which parental controls are required (these are in the process of being implemented).

Seems reasonable to me, that users who can add packages without additional authentication, should be able to remove those packages. What's the contrary argument?

I think the fear is that the unprivileged user could uninstall something important. It's unclear to me why this would be more concerning than allowing unprivileged users to install unwanted software systemwide.

I'm struggling to parse this issue: what's the short issue summary, and what's being proposed as the fix?

TL;DR: Either allow unprivileged users to remove software, or stop allowing unprivileged users to install software. One or the other. I don't care which. The status quo just doesn't make sense.

It's worth being clear about what the use cases are here. Single user system is the main case and a key one to focus on.

This proposal primarily affects multiuser systems, because on single user systems, the user is an admin and already has permission to both install and remove software. My proposed change here is to no longer prompt for admin password in this case.

For multi-user I generally limit it to small home installations, where you have a small number of people with a relatively high degree of trust. Child accounts are a slightly special case for which parental controls are required (these are in the process of being implemented).

Multi-user installations could be family computers, corporate setups, universities, computer labs, etc. All except families should have enough know-how to install a polkit rule to change default permissions.

Sorry, I have to totally reverse myself. I misread this as "unauthenticated admin user can install but not remove" packages. I think install/remove RPMs should require a) admin/wheel user, and b) authentication, because so many areas can be touched by an RPM installation or removal.

Maybe there's adequate selinux access control that somehow could safely permit conforming RPMs to be installed/removed by unprivileged users, but I don't know anything about that possibility. But at least on macOS and Windows, only admins can install/remove software, and at least by default the software package must be signed by a trusted party.

For flatpaks, I think any user should be allowed to install to/remove apps from their user environment, without authentication. What happens behind the scenes: where the flatpaks are stored, deduplication, compression, are details I'm interested in but likely don't relate to the issue and may not be that relevant for Fedora (more relevant for e.g. Endless, perhaps).

I think the fear is that the unprivileged user could uninstall something important. It's unclear to me why this would be more concerning than allowing unprivileged users to install unwanted software systemwide.

Thanks for the clarification, Michael!

I think it's worth being aware that the disparity in the policy is an abstract issue that most users won't be aware of. If we are to focus on the experience of real users, the only issue is that it's annoying for them to have to enter their passwords if they want to remove an app. This is particularly galling in a single user scenario, which is by far the most common case.

If I were to hazard a guess as to the motivation for the existing policy, it would be that we generally want users to be able to install apps, even if the user is unprivileged (since app installation is pretty critical to making the system useful). However, we don't want users potentially causing damage to other users' setups by removing their apps and potentially even causing data loss.

This proposal primarily affects multiuser systems, because on single user systems, the user is an admin and already has permission to both install and remove software. My proposed change here is to no longer prompt for admin password in this case.

I'd be strongly in favour of removing the password prompt for admins to remove software - it's super annoying and the case for it seems weak.

I'm less certain about changing the policy for non-admin accounts. You generally do want to be able to install apps if you're a non-admin, but being able to remove them system-wide could be damaging. The real answer here is to install per-user, but in the absence of that, the current rather odd policy might be the best compromise available.

Multi-user installations could be family computers, corporate setups, universities, computer labs, etc. All except families should have enough know-how to install a polkit rule to change default permissions.

Right, I think we only have to concern ourselves with small home/personal setups. Anything bigger and we expect a sysadmin to be able to tweak the policies themselves.

Note that the new parental controls make some assumptions about what unprivileged users can and can't do, and any changes we make here could have repercussions there.

I think install/remove RPMs should require a) admin/wheel user, and b) authentication, because so many areas can be touched by an RPM installation or removal.

Software doesn't do generic RPM install/remove - it's only for apps or some specific types of packages (codecs, fonts, input methods, etc).

For flatpaks, I think any user should be allowed to install to/remove apps from their user environment, without authentication.
...

Flatpak installs system-wide by default. I'm not sure if it would be wise to change that... (we could find out).

For flatpaks, I think any user should be allowed to install to/remove apps from their user environment, without authentication.
...

Flatpak installs system-wide by default. I'm not sure if it would be wise to change that... (we could find out).

It makes sense to me that Administrators install flatpaks system-wide. Standard users would install with --user. I guess with this scenario, nobody needs to authenticate.

If I were to hazard a guess as to the motivation for the existing policy, it would be that we generally want users to be able to install apps, even if the user is unprivileged (since app installation is pretty critical to making the system useful). However, we don't want users potentially causing damage to other users' setups by removing their apps and potentially even causing data loss.

Thing is, removing apps doesn't cause data loss. This just uninstalls an RPM, it's not going to go into your home directory and start purging files. I don't understand the case that removing systemwide apps could be damaging but installing systemwide apps is somehow fine.

It makes sense to me that Administrators install flatpaks system-wide. Standard users would install with --user. I guess with this scenario, nobody needs to authenticate.

+1

If I were to hazard a guess as to the motivation for the existing policy, it would be that we generally want users to be able to install apps, even if the user is unprivileged (since app installation is pretty critical to making the system useful). However, we don't want users potentially causing damage to other users' setups by removing their apps and potentially even causing data loss.

Thing is, removing apps doesn't cause data loss. This just uninstalls an RPM, it's not going to go into your home directory and start purging files. I don't understand the case that removing systemwide apps could be damaging but installing systemwide apps is somehow fine.

Data loss wasn't the main point I was making. My main point is that apps being removed by other users is really disruptive and is a negative experience. I really think that it's important for us to preserve users' control over their own desktops, even if changes made by other users can be reversed. Your desktop is your personal domain - it's not something another user should be able to inadvertently change.

It makes sense to me that Administrators install flatpaks system-wide. Standard users would install with --user. I guess with this scenario, nobody needs to authenticate.

Way back, I argued that the default behaviour should be per user installation for everyone, on the basis that app choice is a personal thing, and because even admins don't necessarily want all their apps being propagated to other user accounts.

In the event I was overruled. If I recall correctly, one of the motivations for doing system installs by default was to save disk space. So I wonder - would user installs for non-admins largely negate that benefit? If so, what's the point in having system install be the default for admins?

Taking Alan's "For multi-user I generally limit it to small home installations" comment into account, now that we have good availability of Flatpaks, I'd tend to say our policy should be:

• Adminstrators can install and remove rpm-applications and flatpaks systemwide
• Non-priviilged users can add and remove flatpaks --user

(Should things that would require more privilege show up in GNOME Software for non-privileged users and trigger prompting for an admin password? Or should they just not show up at all?)

I don't think allowing unprivileged users to remove apps systemwide that they didn't install is a good idea at all.

Data loss wasn't the main point I was making. My main point is that apps being removed by other users is really disruptive and is a negative experience. I really think that it's important for us to preserve users' control over their own desktops, even if changes made by other users can be reversed. Your desktop is your personal domain - it's not something another user should be able to inadvertently change.

I agree, but that argument applies just the same to prevent unprivileged users from installing systemwide apps. Also, it's certainly not clear why this would be considered more important than allowing users to undo changes. Being able to install something, but not uninstall it, is very frustrating. A reasonable user would expect to be able to install an app, try it out, not like it, and uninstall it. Locking unprivileged users into retaining an unwanted app is not nice.

In the event I was overruled. If I recall correctly, one of the motivations for doing system installs by default was to save disk space. So I wonder - would user installs for non-admins largely negate that benefit? If so, what's the point in having system install be the default for admins?

Well nowadays we have had many problems with users running out of disk space in /, which used to be only 50 GB. Disk space is not nearly as problematic under /home because /home is very large.

Taking Alan's "For multi-user I generally limit it to small home installations" comment into account, now that we have good availability of Flatpaks, I'd tend to say our policy should be:

Adminstrators can install and remove rpm-applications and flatpaks systemwide
Non-priviilged users can add and remove flatpaks --user

This is what I'd like to see.

(Should things that would require more privilege show up in GNOME Software for non-privileged users and trigger prompting for an admin password? Or should they just not show up at all?)

Well unprivileged users should at least see RPMs, or the software center content would be mysteriously lacking. I don't think we necessarily need to expose systemwide flatpak installation to unprivileged users, or expose --user installation to admin users, but we could. Unprivileged users will see systemwide flatpaks in gnome-software if installed by an admin user, so we need to be prepared to prompt for a password to remove them regardless.

Locking unprivileged users into retaining an unwanted app is not nice.

That is true, but I would say that not allowing them to install apps is worse, and allowing them to remove the apps of other users is worse.

Given that, at present, someone has to manually enable Flathub in order to get a useful Flatpak experience, I wonder whether we can really take Flatpak into account when we decide on the behaviour for RPMs. Can we really ignore RPM-only systems?

Re: flatpak apps only

--user implies the app goes in ~/.var, which might be a nice default today, to avoid the space consumption problem with a small sysroot size. This is less of a concern if there's one large storage pool.

However, systemd-homed suggests portable homes and thus portable apps. It's not clear to me what the user expectation is, whether and how to inform them, or give them a choice. Or even whether home portablity is a (sub)feature Workstation will promote. Further, portable homes presents a new distinction: a non-admin user is in some sense the root user of the USB storage device they're providing that also contains their user home.

Another systemd-homed distinction is support for user home storage quotas. Right now, an unprivilege user can hog all the space on /home they want; and in the case of one big storage pool, they can hog all of that too. This is limited in a systemd-homed context.

I think things are, in practice, becoming more nuanced than strictly --system or --user, including the privilege question.

Consider the following design:

• At least one admin user must exist
• Any user can install apps
• Secondary authentication is never required for any user to add/remove apps
• Apps are always installed to /var by default
• Apps are owned by the user who installs them
• Apps can be removed by their owner or by admin
• All users see apps install to /var

Alternative 1:

• Apps can be removed by any user; however if removed by a non-admin and non-owner of that app, it only removes that app's visibility for the user conducting the removal i.e. it's merely hidden.

Alternative 2:

• Admins see all apps
• Non-admin users see only apps they own
• Non-admin users can still "install" apps that are already installed, but this has the effect of just creating an icon for the app in Activities.

The point here is, in a multi user system, do you really want app duplication unnecessarily taking up extra space?

As for apply this same design to RPM, I don't know if it can handle such nuance.

Following from the above, with both alternative 1 and 2:

Owen and Chris are standard users. Owen installs AstroMenace, and needs no privileges or secondary authentication to do so (aside from parental controls). Owen tells Chris it's badass and he should install it too. When Chris installs it, he gets an app icon for it, the flatpak app binary is shared. They're now co-owners of this app. Owen uninstalls it, and no longer sees the app icon. Chris can still use the app. When he uninstalls it, the flatpak app binary is deleted.

Closing this issue, because it's premised on a misunderstanding of our polkit policy. Sorry for wasting everyone's time.

We don't allow unprivileged users to install software. Period. Sorry, I was totally wrong.

We allow admin users to install software without a password prompt (but a password is required to remove it). This doesn't make sense either, but it's not a question of what you can do -- as an admin, you can install or remove whatever you want -- it's just a question of what you have to enter a password to do (to protect against attackers who gain physical access to your computer while it is unlocked).

BTW I'm going to propose upstream that we allow local admin users to remove software without password prompt. The real parallelism error here was that admin users can install, but not remove, software without entering their admin password. (@kalev, do you agree?)

I agree that it's weird that install/remove behave differently. I think it's good user experience to be able to undo an operation without requiring additional permissions.

I wasn't involved in any way with the original decision and that's all between hughsie/mclasen/aday I believe.

https://github.com/hughsie/PackageKit/pull/404

I believe flatpak and rpm-ostree have similar (matching) policies that would need updating if your PackageKit change is accepted.

flatpak already allows uninstall.

I couldn't find existing policy JavaScript for rpm-ostree. I suspect it always requires admin password?

OK, great! Thanks for checking.

rpm-ostree js policy is in fedora-release

Looks like rpm-ostree uses the same permission for both installing and removing software, i.e. it's not possible to require password for one but not the other. We don't require password (for local admin users).

OK, great! I did the initial polkit support in rpmostreed and I guess I didn't even consider that someone might want to have different policy rules for install and uninstall :D