Agreed, this would be a very useful feature.

Is this actually about github-oauth? Looks more like a core issue to me...

That being said, this is a horrible idea, and here's why:

• Admins don't usually know the security implications of making arbitrary URLs accessible
• Admins don't even know all URLs provided by core and plugins (or did you know /descriptor/hudson.triggers.SCMTrigger?)
• Changes in configuration might lead to accidental exposure of newly added URLs because of some carelessly written regex.
• To the best of my knowledge, there's no way to reliably enumerate all possible URLs.

The sensible approach is to implement UnprotectedRootAction in plugins where the authors considers the security implementations.

FWIW a plugin could probably manage to add this functionality by acting as an internal proxy of sorts (Build Token Root plugin on steroids). But this should never be part of the default configuration, and should have come with warnings regarding its use (similar to Anything Goes Markup Formatter).

I can't speak to core stuff as I know little to nothing about it but I have the same problem with the plugin mentioned above. I want to show build status on a public page but I don't have a way to do using github-oauth without being too permissive.

Just allowing that build status URL to be public would work for me.

Embeddable build status seems to have implemented this for JENKINS-17798 in version 1.4. Just give anonymous the "View Status" permission globally, and access /buildStatus/icon?job=yourjobnamehere. Finer grained access using e.g. project-based matrix permissions. If a user only has this permission, no access to the project in Jenkins is granted otherwise, so it should be safe enough.

But I don't want to give anonymous the "view status" permission globally
I don't even see that option when using the github-oauth plugin for authentication, I only see "Grant READ permissions for Anonymous Users" which might be the same.

My apologies. I've completely missed that Github OAuth plugin doesn't just do authentication, but also authorization.

In that case, it seems that it's simply missing a way to assign permissions fine-grained in Jenkins. What it absolutely cannot do (given the APIs and assuming reasonable effort) is to allow access to URL regexes, as that's not how Jenkins (or rather Stapler) works internally.

This seems to be a design limitation in the plugin (note that I've never used it, just read some docs!): From its description, it seems to assign permissions to Jenkins based on characteristics of the account on Github (e.g. org membership), rather than setting just a list of granted authorities (similar to group memberships in other user directories) and allow use of arbitrary authorization strategies – then you'd be able to use Role Strategy Plugin or the Matrix Auth Plugin. Given that many plugins now are introducing additional permissions, this design limitation seems to become worse over time.

I'll leave this open and on the github-oauth component, as any solution should probably be introduced there.

Since this issue is over a year old I am closing it. Try using the latest release. If it is still an issue in the latest release then file a new issue and link back to this one.

This issue was resolved with release 0.21.1. https://github.com/jenkinsci/github-oauth-plugin/pull/29

Additionally one can make use of a matrix-based authorization strategy. GitHub users are surfaced as Jenkins users. GitHub teams and groups are surfaced as Jenkins Groups. It is documented in the wiki: https://wiki.jenkins-ci.org/display/JENKINS/Github+OAuth+Plugin