Fedora Silverblue: How to update policy rules to allow rpm-ostree rollback with non-admin users?

Ask Fedora
,
1

Situation

I have a laptop with Fedora 35 Silverblue and 2 accounts set up: Admin and User.

On one hand, I would like to prevent User from changing (i.e.: installing/uninstalling) software with rpm-ostree. That means, force them to use workspace when in need of an RPM package and leave the system untouched.

On the other hand, I would like to make sure the system is up to date (i.e.: User has the latest system updates without any Admin intervention).

Question 1: Will the system be updated without User intervention?

I configured GNOME Software to download and install automatic updates. Does this also apply for system updates and when only User is logged in? (i.e.: will User always have the latest system updates without needing to run rpm-ostree upgrade by hand?)

Question 2: How to allow User to rollback?

Even if this was the case, I would like to allow User to rollback in case a system upgrade goes wrong, but without adding User to the wheels group. How can I do that?

I tried editing /etc/polkit-1/rules.d/90-user.rules:

polkit.addRule(function(action, subject) {
    if ((action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.upgrade" ||
        action.id == "org.projectatomic.rpmostree1.rollback") &&
       subject.active == true && subject.local == true) {
           return polkit.Result.YES;
    }
});

But it seems this file did not persist across reboots.

What is the best way to allow User to upgrade/deploy/rollback without letting them install/uninstall packages from the system and without allowing them any other Admin privileges?

2

Best way to keep the system updated is to enable the rpm-ostreed.service. This will run the updates in the background without user intervention.

I would not allow a “normal” user to allow rollback. In the event that they need to use a previous deployment, they can simply choose that previous deployment in the GRUB menu during boot.

2 Likes
3

Thanks for the pointer! :heart:

I will wait a bit before marking it as the accepted solution in case someone else wants to share a different point of view. :blush:

4

It seems the linked blog post shared by @guiltydoggy assumes you have a specific content written in the configuration file. In my case, the AutomaticUpdatePolicy line was commented and had a none value set, instead of check. I’ll leave here the general instructions for future reference.

All the information on how to perform this change can be found by having a look at:

man rpm-ostreed.conf

Adapting the provided example just to use the stage policy:

Enabling the automatic updates “stage” pollicy is a two step process. First, edit /etc/rpm-ostreed.conf to include AutomaticUpdatePoicy=stage and then use rpm-ostree reload to reload the rpm-ostreed service. Next, enable the timer using systemctl enable rpm-ostreed-automatic.timer --now

When successful, the output from rpm-ostree status will display output similar to the following:

$ rpm-ostree status
State: idle; auto updates enabled (stage; last run 22min ago)
…

2 Likes
5

So did this work for you? Can non-wheel users now do the upgrade, rollback and deploy?