WORKSPACE permission and viewing workspace files using plugins
9 views
Skip to first unread message
Ullrich Hafner
Nov 21, 2017, 7:46:29 AM11/21/17
to Jenkins Developers
I have a question on how to interpret the permission WORKSPACE in plug-ins. As far as I understand the changed documentation in [1] this permission should only be evaluated when trying to view workspace files using the workspace browser.
However, in my static analysis plug-ins I implemented a more restrict rule (since this part of my plugins has been implemented before the changes in [1]): if the current user does not have the permission WORKSPACE, then the source code of affected files is not shown (just the warning). See [2] as an example, here you see the warning but not the source code. On the other hand, jacoco and the git plugin show the sources even if the permission is not set. So I wonder, how we (as plugin authors) should treat this situation? Does it make sense to check for this permission? Then other plugins need to implement that permission check as well. Or should I remove this restriction from my plugins? Or should there be an additional global permission in Jenkins? Or is this just plugin specific and I can handle it in my way? What do you think?
Or more specifically, what is the idea behind the WORKSPACE permission? What do we want to prevent with this permission? Currently, our CI builds have this permission disabled for anonymous users, so I can’t see the warning details for PRs.
[1] https://issues.jenkins-ci.org/browse/JENKINS-20148?focusedCommentId=320330&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-320330
[2] https://ci.jenkins.io/job/Plugins/job/analysis-model/job/coverage/5/findbugsResult/package.91569697/
[3] https://ci.jenkins.io/job/Plugins/job/analysis-model/job/coverage/5/jacoco/edu.hm.hafner.analysis/FastRegexpLineParser/
However, in my static analysis plug-ins I implemented a more restrict rule (since this part of my plugins has been implemented before the changes in [1]): if the current user does not have the permission WORKSPACE, then the source code of affected files is not shown (just the warning). See [2] as an example, here you see the warning but not the source code. On the other hand, jacoco and the git plugin show the sources even if the permission is not set. So I wonder, how we (as plugin authors) should treat this situation? Does it make sense to check for this permission? Then other plugins need to implement that permission check as well. Or should I remove this restriction from my plugins? Or should there be an additional global permission in Jenkins? Or is this just plugin specific and I can handle it in my way? What do you think?
Or more specifically, what is the idea behind the WORKSPACE permission? What do we want to prevent with this permission? Currently, our CI builds have this permission disabled for anonymous users, so I can’t see the warning details for PRs.
[1] https://issues.jenkins-ci.org/browse/JENKINS-20148?focusedCommentId=320330&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-320330
[2] https://ci.jenkins.io/job/Plugins/job/analysis-model/job/coverage/5/findbugsResult/package.91569697/
[3] https://ci.jenkins.io/job/Plugins/job/analysis-model/job/coverage/5/jacoco/edu.hm.hafner.analysis/FastRegexpLineParser/
Robert Sandell
Nov 21, 2017, 11:03:49 AM11/21/17
to jenkin...@googlegroups.com
IIRC the intention of the permission was to hinder users who don't have access to read the repo to retrieve the source code by "other means" i.e. through the Jenkins workspace browser.
/B
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F233B486-499C-43A8-AEAA-C24411587234%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Robert Sandell
Software Engineer
CloudBees Inc.
Reply all
Reply to author
Forward
0 new messages