Well, currently admin monitors are displayed in the UI only (also in support-core diagnostic bundles). If you ignore security and other warnings displayed this way, there is not much we can do.

I wonder whether an admin monitors CLI command would make sense. Unfortunately output is tailored to HTML, so would need to be limited to visible yes/no.

The original request didn't mention the UI or admin monitors. The presumption on jglick part that I'm not looking at the UI monitor is not relevant to what is being requested. I totally get if there are limitations in the console output for the case I presented - please feel free to close this request out if the addition is not possible.

Thanks for taking the time to look at this.

brenna_flood

The original request can be fixed neither in the plugin nor in core (at least not with any sort of reasonable effort). That doesn't mean you don't describe a problem it's worth investigating possible solutions for.

brenna_flood

FWIW, this…

As such, in order to install plugins, this is done as anonymous - and chef has been able to do this without issue as long as anonymous has access to UploadPlugins.

… is a good example why we felt the need to implement this, and do it in a way that gives maximum exposure to the issue to make admins aware.

If you're able to upload plugins, then you can trivially write the give-my-user-admin-permissions.hpi plugin and upload it. Or the extract-all-valuable-data.hpi plugin.

Therefore, Anonymous should also not have any of these three permissions either, or all the users on your network have all the permissions, and can do whatever they want if they are willing to do the effort.

Yep, I totally agree on this point.

The reason for opening the issue was that the current setting will drive some users towards setting UploadPlugins AND Administer as a "fix" for this.  It seems the changes made are regressive.

brenna_flood

the current setting will drive some users towards setting UploadPlugins AND Administer as a "fix" for this

That's fair, but…

1. We highlight the backward compatibility option both in the plugin docs (well, their wiki pages) and the directly security advisory. The idea/hope/delusion is that users who absolutely cannot go without will just do that, and nothing will have changed for them.
2. They will be doing it very aware of what they're doing. You can't not know that you're granting Administer to anon, and setting a flag called "dangerous" to true is similarly unambiguous.

Previously, users may has assumed that, for example, granting Run Scripts is safe. In fact, I bring proof in the form of the Scriptler Plugin documentation (and that was written by a long time contributor to the Jenkins project who still was unaware what exactly he was recommending there): https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin

You are able to configure whether you want to allow users which have only the "RunScripts" permission to execute scripts (every script has to be allowed separately). In addition you can also configure if these users should be able to change a script (which would be a security issue).

Now, at least, the unsafe behavior is opt-in.

danielbeck brenna_flood So do we need any actions here? From what I see, "no"

I haven't seen similar requests in response to the April permission changes, and of the 4 watchers, 3 are core team. It sucks that it probably confused brenna_flood for a while, but as I commented before, there are no straightforward fixes that I can see that wouldn't e.g. cause effective regressions. So spending time on this wouldn't really be time well spent IMO.

I am closing it for now.

If there are any particular improvements in diagnostics to be done, let's discuss them in follow-up tickets