Passwordless use of pamac only for upgrades?

My goal: to be able to do pamac upgrade --no-confirm from the CLI without it asking for my password.

My first naive attempt was to put the command in an upgrade script, add it to sudoers with NOPASSWD and add an alias sudo upgrade. This worked just peachy until I read the dire warnings about using pamac with sudo; as the docs say:

Using sudo with pamac can have undesirable effects, especially when building packages. if in doubt, don’t use sudo. Pamac will ask for escalated rights if needed.

And as mentioned elsewhere on the forum the main risk for building is that this may kick off arbitrary AUR scripts as root, which is generally seen as a Bad Thing. Fair enough, but I don’t use AUR packages.

The accepted solution for running pamac without authorization is to create a custom polkit rule (mentioned here), but there seems to be no granularity to this: doing this means I’ll no longer be prompted for a password on any action that requires elevation, including removals, reinstalls and whatnot. This is broader than what I want.

This basically leads me to two closely related questions:

  1. What exactly are the “undesirable effects” that can happen when running pamac with sudo? Do they only happen with pamac build, or more precisely, is there any chance of them happening with pamac upgrade, as that will be the only command I’ll have running with elevation? Are they only related to AUR packages?
  2. Is my first approach with a shell script sound? Should I maybe just fall back to an appropriate sequence of pacman commands, which appears to be happy with sudo? I like pamac exactly because it sands off the nasty edges of pacman, so I wouldn’t know what the appropriate sequence of commands is, but obviously I can put in the effort.

Note that this is all mostly academic. I’m not hugely opposed to pamac never asking for a password since I really don’t expect some rogue script to start running pamac remove out of the blue so the polkit approach will do fine for practical purposes, but it would still be nice to know.

I know this is not exactly an answer to your question.

But what is your intention on making updates not asking for increased privileges?

They are in fact installing and removing installed packages and therefore are just as critical.
Furthermore if you don’t agree and just want updates to happen without permission, pamac has settings to load and install updates automatically.

Edit: guess I should have payed more attention to this.

Basically I want the “potentially break my system now” button to always be a button that I press explicitly; I definitely don’t want things to auto-update in the background. But I’m still lazy enough that I don’t want to have to enter my password every time I press that button since I’ll probably press it every time after logon (this system is not on frequently).

If pamac upgrade decides to remove packages, I’m willing to give it the benefit of the doubt. If on the other hand I (or really anything) does a pamac remove of a specific package, I don’t want that to be automatic.

The solution itself does not do what you want … but polkit rules by nature are granular.

Multiple - including that it breaks the way pamac is supposed to run.
In the same you should not be using root on your HOME files or running steam with sudo etc etc.
It negatively impacts any way you use it.
Using it with the AUR simply makes it worse, especially in terms of security.

Which also brings us to another point, that I will roll into the next section

If you intend to use sudo over polkit, as well as use the cli, and avoid the AUR … I really dont know why you wouldnt use pacman instead.

Forgoing all good sense to argue that one should not do any of this
(passwordless upgrades, automated, and noconfirm)
The command equivalent in pacman is quite simple;

sudo pacman -Syu --noconfirm

The solution itself does not do what you want … but polkit rules by nature are granular.

Out of curiosity, is there a way to write the polkit rule in a granular manner? I checked the definition of the pamac policy, but the only action there seems to be org.manjaro.pamac.commit, which just covers all “do things with packages now” AFAICT. Is there some other attribute that makes the action more specific?

In the same you should not be using root on your HOME files or running steam with sudo etc etc.

Yes, to be clear I don’t mean “what could possibly go wrong if you use root”, as the answer there is simply “well things could be happening with elevation that shouldn’t be happening”. But as package managers obviously do need to make things happen with elevation, it’s not clear why pamac is specifically different here.

The command equivalent in pacman is quite simple;

sudo pacman -Syu --noconfirm

So to be clear, this is the same thing as pamac upgrade --no-confirm, with no other “niceties” pamac performs?

Sorry, I am not familiar enough with pamac to be able to tell you how, or even if it is possible.
I dont have any installed files to look at. :wink:

I just know it can be so long as the software supports it.
As seen in the archwiki example that is specific for a single systemd service;

polkit.addRule(function(action, subject) {
    if ( == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "wpa_supplicant.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                return polkit.Result.YES;

polkit - ArchWiki

How pamac is invoked and in turn passes arguments.
It assumes it is dealing with a regular user.
So things like where/how to place cache files is done with syntax appropriate for a regular user.
Thats a basic problem.
Its also a problem to forcibly mix multiple privilege mechanisms.
sudo doas pkexec pamac is somewhat obviously a problem.
You mentioned how handing privileges to foreign build scripts is also recognizably bad so I wont have to describe it again here.

Theres virtually no ‘niceties’ that pamac does perform.
It supports extra package formats like Flatpak, and the AUR.
The only thing that might qualify is that pamac can/does supposedly downgrade packages that are newer than in the repos automatically. Whereas with pacman you would need to explicitly allow this by using 2 u’s.

sudo pacman -Syuu

Pamac also has weird problems with keeping in sync with mirrors apparently so something like --force-refresh is sometimes needed but with pacman you virtually never require the equivalent double y -Syyu (in fact it is advised against unless you really need it).

You do know that pamac gui has two settings that let it download updates and install them at a restart. This never prompts for a password, perhaps it should?

Yeah, that confirms the policy description of actions is not exhaustive (as in, you don’t know what’s available through lookup, since /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy only contains the ids and descriptions). As the polkit docs helpfully state, please look at the docs of the software involved for that. :stuck_out_tongue: If I get bored I might dig into pamac further to see if it does anything more involved with the action, I couldn’t find it in 5 minutes of grepping the source in any case. I suspect it doesn’t since, as you mentioned, an upgrade could be a tangle of different actions anyway.

Update: confirmed it doesn’t (I was looking at pamac when the real action happens in libpamac), the relevant line is here and the call doesn’t include any details for the action:

var result = yield authority.check_authorization (

It arguably should when you toggle the options, yes. In any case that’s not what I’m looking for, though it may be useful to others. I prefer the CLI so I can more clearly read back what happened without opening textboxes, and I certainly don’t want the updates to happen automatically at shutdown.

In any case I think my questions have been sufficiently answered, so I’ll mark up a solution.

Just a couple of notes for my post above.
It ignores AUR updates and what it has done is still in the history output.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.