Open Stack

Hi Thanh,


Comments inline.


On 7 June 2016 at 21:35, Thanh Ha <thanh.ha at linuxfoundation.org> wrote:

> Taking a look at the code, I realized the test command allowed spoofing of
> the plugins_info. I thought I'd try and see what happens if we allowed
> spoofing with the update command too and submitted this patch:
>
>     https://review.openstack.org/326722
>
> I'm wondering if this could be a possible solution to the Administrator
> permissions issue assuming that providing the plugins_info yaml file causes
> JJB to not query the live Jenkins system for the info.
>

Definitely worth looking at, though probably worth digging in first to
understand why the information couldn't be retrieved in case some
documentation is needed to help users.



> On 7 June 2016 at 15:34, Thanh Ha <thanh.ha at linuxfoundation.org> wrote:
>
>> Hi Everyone,
>>
> <snipped>

> Unfortunately it's come to our attention that this feature in Jenkins
>> requires the Administrator permission which can be problematic if you have
>> an environment where you prefer not to give this permission out. I think
>> the ideal solution is to build into Jenkins a separate permission for
>> viewing plugin information. I'll try contacting Jenkins devs to see if this
>> is something they can do inside Jenkins.
>>
>

Curious to know what version of Jenkins you used? Is this a new security
feature added by recent versions, or is it something depending on what
other permissions have been enabled by default for various users?

Because I can query a 1.565.3 installation of Jenkins for it's list of
plugins as an anonyous user using the following URL:

<jenkins-baseurl>/pluginManager/api/json?depth=1

Perhaps it's a new behaviour for the 2.x series to prevent access to this
part of the XML API by default?

Definitely worth following up with Jenkins devs after looking closely at
the permissions with your



> Failing that maybe we can somehow make the plugin info optional in JJB?
>> any thoughts around this topic?
>>
>> One of our use cases with this is that we have a sandbox instance of
>> Jenkins deployed for our community to test jobs with however for obvious
>> reasons we cannot give folks administrator access to this instance but
>> unfortunately if someone is trying to use a plugin (such as the Slack
>> plugin) that needs to inspect plugin versions jjb fails to push the job.
>>
>

I'd like to know what's changed either way, if we do need additional privs
to read this information over being a normal user, or if some privilege in
something like the matrix security plugin or role based authentication
plugin is needed, it would be important to be able to call this out in the
documentation.

That way if you don't want to make this information directly available to
JJB, you could still allow an approved script (that runs with higher
privileges) to be run as a build step to generate the plugins info for it
to be read in by the user running JJB.

-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160608/165e9aef/attachment.html>