Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JENKINS-61206 - Support System Read / Extended read permissions for agent configurations #4531

Merged
merged 27 commits into from
May 24, 2020

Conversation

timja
Copy link
Member

@timja timja commented Feb 29, 2020

See JENKINS-61206.

Adds system read / extended read support for agents / clouds.

The rule I applied was anything that was previously checking for administer for viewing is now system read, anything checking for connect or configure is Agent/ExtendedRead

Manual testing notes

When using the core-pr-tester (docker run --rm -ti -p 8080:8080 -e ID=4531 jenkins/core-pr-tester), you can use script console to enable the permissions:

Jenkins.SYSTEM_READ.enabled = true
Computer.EXTENDED_READ.enabled = true

Proposed changelog entries

  • Entry 1: JENKINS-61206, Add system read support for 'Node Monitoring Configuration' and configuring clouds
  • Entry 2: JENKINS-61206, Add Agent/ExtendedRead support for viewing agent configuration, system information and logs
  • Entry 3: JENKINS-61206, Add support for the permissions attribute to task.jelly
  • Entry 4: JENKINS-61206, Add hasAnyPermissions API to Functions to allow it to be called by views
  • ...

Proposed upgrade guidelines

N/A

Submitter checklist

  • JIRA issue is well described
  • Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
  • Appropriate autotests or explanation to why this change has no tests
  • For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

  • There are at least 2 approvals for the pull request and no outstanding requests for change
  • Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
  • Changelog entries in the PR title and/or Proposed changelog entries are correct
  • Proper changelog labels are set so that the changelog can be generated automatically
  • If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
  • If it would make sense to backport the change to LTS, a JIRA issue should exist and be labeled as lts-candidate

@timja timja added web-ui The PR includes WebUI changes which may need special expertise developer Changes which impact plugin developers labels Feb 29, 2020
@daniel-beck daniel-beck self-requested a review February 29, 2020 12:55
/**
* This version is so that the 'hasAnyPermission'
* degrades gracefully if "it" is not an {@link AccessControlled} object.
* Otherwise it will perform no check and that problem is hard to notice.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just throw in that case? The assumption that object is an ancestor isn't necessarily true. For example, in upstream cause related UI, you would show information about another job / build.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’s consistent with hasPermission and wasn’t working without this for the l:task it was just silently doing nothing

@timja timja closed this Mar 1, 2020
@timja timja reopened this Mar 1, 2020
@timja timja closed this Mar 5, 2020
@timja timja reopened this Mar 5, 2020
@daniel-beck daniel-beck self-requested a review March 6, 2020 23:06
@daniel-beck
Copy link
Member

f:password has specific support to hide the password when it's shown in the context of an Item. This implemented a security fix (users without Configure/with Extended Read could see plain text or encrypted passwords on the config form).

if (req != null) {
Item item = req.findAncestorObject(Item.class);
if (item != null && !item.hasPermission(Item.CONFIGURE)) {
return "********";
}
}

While this is now pretty irrelevant for "read only" forms, it's not inconceivable that other views are added by a plugin that are available to users with Computer/ExtendedRead but are not marked read-only.

So I would like to see that method amended to mask f:password when neither Computer/Configure permission is granted, nor readOnlyMode set.

@timja
Copy link
Member Author

timja commented Apr 24, 2020

f:password has specific support to hide the password when it's shown in the context of an Item. This implemented a security fix (users without Configure/with Extended Read could see plain text or encrypted passwords on the config form).

if (req != null) {
Item item = req.findAncestorObject(Item.class);
if (item != null && !item.hasPermission(Item.CONFIGURE)) {
return "********";
}
}

While this is now pretty irrelevant for "read only" forms, it's not inconceivable that other views are added by a plugin that are available to users with Computer/ExtendedRead but are not marked read-only.

So I would like to see that method amended to mask f:password when neither Computer/Configure permission is granted, nor readOnlyMode set.

The only usages of Computer.EXTENDED_READ are currently in jenkins core, this feature has never been documented, and it not enabled by the extended read permission plugin, I will fix that as part of this work.

I see it as pretty inconceivable really.

Do you still think it's worth doing that?

@daniel-beck
Copy link
Member

@timja I do, any plugin adding support for Computer/Extended Read without also ensuring their custom form is readOnlyMode would enable this problem.

To clarify, it is not currently a problem for the reasons you mention, but may become one with this PR.

@timja
Copy link
Member Author

timja commented Apr 24, 2020

Hmm k, will take a look

@timja
Copy link
Member Author

timja commented Apr 25, 2020

@timja I do, any plugin adding support for Computer/Extended Read without also ensuring their custom form is readOnlyMode would enable this problem.

To clarify, it is not currently a problem for the reasons you mention, but may become one with this PR.

Pushed, will look at a test later on, I've manually tested it

@timja
Copy link
Member Author

timja commented Apr 25, 2020

@timja I do, any plugin adding support for Computer/Extended Read without also ensuring their custom form is readOnlyMode would enable this problem.

To clarify, it is not currently a problem for the reasons you mention, but may become one with this PR.

For testing, any suggestion on how to add a form with a Computer in it's ancestor but not in what's already got readOnlyMode as part of this PR?

I tested it by commenting out the readOnlyMode and adding a secret field to JNLPLauncher

@daniel-beck
Copy link
Member

daniel-beck commented Apr 25, 2020

For testing, any suggestion on how to add a form with a Computer in it's ancestor but not in what's already got readOnlyMode as part of this PR?

@timja Attach an Action to the Computer (or Slave I never remember which) with a view that has an f:password.

@timja
Copy link
Member Author

timja commented Apr 28, 2020

For testing, any suggestion on how to add a form with a Computer in it's ancestor but not in what's already got readOnlyMode as part of this PR?

@timja Attach an Action to the Computer (or Slave I never remember which) with a view that has an f:password.

resolved in 393ad7f

@timja timja requested review from jvz and jeffret-b April 28, 2020 20:43
<l:task href="${rootURL}/${it.url}configure" icon="icon-setting icon-md" permission="${it.EXTENDED_READ}" title="${%Configure}"/>

<j:choose>
<j:when test="${app.hasPermission(it.CONFIGURE)}">
Copy link
Member

@daniel-beck daniel-beck May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the same mistake that made all job configurations read-only?

Suggested change
<j:when test="${app.hasPermission(it.CONFIGURE)}">
<j:when test="${it.hasPermission(it.CONFIGURE)}">

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to work though, =/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've committed it but both seem to work in this case from what I can see

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't grant the permission globally, use project-specific matrix auth and grant it on the specific agent only.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm ? That’s what’s there now isn’t it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah you mean when I was testing before sure

@daniel-beck daniel-beck self-requested a review May 8, 2020 17:32
@amuniz
Copy link
Member

amuniz commented May 13, 2020

I've created #4724 which will generate some merge conflicts with this. I'm happy to resolve conflicts there is this is merged first (or help to resolve conflicts here if needed).

@timja
Copy link
Member Author

timja commented May 15, 2020

@daniel-beck would you be able to take another look please?

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't fit as a line comment, so mentioning it here: It would be good if users with Overall/SystemRead were able to see the global cloud configuration that now only says

The cloud configuration has moved to a separate configuration page.


I see nothing wrong with this PR, even in manual testing. Thanks for adding proper Computer/ExtendedRead support.

@timja timja requested a review from a team May 19, 2020 15:23
@timja
Copy link
Member Author

timja commented May 19, 2020

Anyone else want to take a look at this?

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-:+1:

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-:+1: assuming latest changes were manually tested.

@oleg-nenashev oleg-nenashev self-requested a review May 20, 2020 08:30
@oleg-nenashev
Copy link
Member

@oleg-nenashev to retest it

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yesterday I spent some time to verify the PR, and it looks good to me. On my test instance the forms worked pretty well with Extended Read. I am +1 for merging and early release so that we could do crowd testing during the hackfest.

Cc @jenkinsci/core , is everybody fine with release on Monday with this fix?

@oleg-nenashev oleg-nenashev added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label May 22, 2020
@timja timja merged commit 634004a into jenkinsci:master May 24, 2020
@oleg-nenashev oleg-nenashev changed the title JENKINS-61206 System read / Extended read for agents JENKINS-61206 - Support System Read / Extended read permissions for agent configurations May 25, 2020
@daniel-beck daniel-beck mentioned this pull request Jul 27, 2020
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer Changes which impact plugin developers ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted squash-merge-me Unclean or useless commit history, should be merged only with squash-merge web-ui The PR includes WebUI changes which may need special expertise
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants