#316 rpm-ostree: allow upgrades for all, require password for changes
Closed 2 months ago by boredsquirrel. Opened 3 months ago by boredsquirrel.
Unknown source rawhide  into  rawhide

@@ -1,14 +1,13 @@

  polkit.addRule(function(action, subject) {

-     if (action.id == "org.projectatomic.rpmostree1.repo-refresh" &&

-         subject.active == true && subject.local == true) {

+     if (action.id == "org.projectatomic.rpmostree1.repo-refresh" ||

+     action.id == "org.projectatomic.rpmostree1.upgrade") {

              return polkit.Result.YES;

      }

- 

+  

      if ((action.id == "org.projectatomic.rpmostree1.install-uninstall-packages" ||

           action.id == "org.projectatomic.rpmostree1.install-local-packages" ||

           action.id == "org.projectatomic.rpmostree1.override" ||

           action.id == "org.projectatomic.rpmostree1.deploy" ||

-          action.id == "org.projectatomic.rpmostree1.upgrade" ||

           action.id == "org.projectatomic.rpmostree1.rebase" ||

           action.id == "org.projectatomic.rpmostree1.rollback" ||

           action.id == "org.projectatomic.rpmostree1.bootconfig" ||
@@ -21,4 +20,4 @@

          subject.isInGroup("wheel")) {

              return polkit.Result.YES;

      }

- });

+ }); 

\ No newline at end of file

There is no need for wheel users to change their system without a password confirmation.

On the other hand, nonwheel users cannot perform any upgrades currently, which is a bad state.

Regular Fedora requires a password for performing such elevated actions, there is no reason to allow this. I use my system with this rule and it works fine.

For a change to permissions like this, I'd really like to see this associated with a formal decision from the involved SIGs somewhere. Do you have a link to such a decision?

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/3733dae2e37640ce807928e1368ded8b

I asked around, and this appears related to https://gitlab.com/fedora/ostree/sig/-/issues/7 which is still under discussion upstream.

I'm going to close this merge request; please resubmit once the upstream discussion is complete.

Pull-Request has been closed by sgallagh

3 months ago

hey, yes that discussion was "dead" for a long time. Mentioned this PR there. @siosm

Pull-Request has been reopened by boredsquirrel

3 months ago

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/39822ad5e57d473284d3a7d83935e6a6

Let's split this into two PRs. First one to add the upgrade permission and a second one to remove some permissions from the wheel section.

We will have to evaluate the security of each one independently to make sure we're not opening something we don't want.

1 new commit added

  • rpm-ostree: allow any user to refresh and upgrade
2 months ago

okay if you think so 🤷🏾

so this is the one to fix updates for nonwheel users, as well as to allow upgrades for all users, remote, not logged in (as far as I understood that part) etc.

Updating and refreshing should not create any attack surface.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/76bad9b0214349ce98f59ff2cbf175f8

Please squash commits and include only the relevant changes, nothing else.

Note that you are also changing the logic around subject.active == true && subject.local == true, which is probably not what we want, at least initially, so let's keep this.

I am currently having trouble with connecting git to pagure (username password auth not working) so as I think this is quite important I will close this PR and open a new one.

Pull-Request has been closed by boredsquirrel

2 months ago

I opened a new PR that first addresses the security critical part of this PR.

For the second one, why should updates be bound to local and active users? Will this break background updates, or updates on systems where users ssh/VNC only?

this is my workaround second account to make poth PRs as quick as possible

this is my workaround second account to make poth PRs as quick as possible

Metadata