Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
src/main/java/com/michelin/cio/hudson/plugins/rolestrategy/RoleBasedAuthorizationStrategy.java
http://jenkins-ci.org/commit/role-strategy-plugin/d62d908d09f488426e0309065b482c23256259fd
Log:
Merge pull request #1 from jglick/folders-JENKINS-17482

[FIXED JENKINS-17482] Support folders.

Compare: https://github.com/jenkinsci/role-strategy-plugin/compare/8ba15e72be46...d62d908d09f4

Does it also works for views?

Not sure what you mean. Views and Folders are very different things. Folders become part of a job's location/identity (so a job can only be in one folder), while views are virtual (one job in multiple views; inclusion of jobs based on filters) and only in the URL to provide the breadcrumb trail.

AFAICT, Role Strategy only has global view permissions, the 'project-based' (i.e. job name regex) part does not use view related permisions:

https://github.com/jenkinsci/role-strategy-plugin/blob/master/src/main/java/com/michelin/cio/hudson/plugins/rolestrategy/RoleBasedAuthorizationStrategy.java#L503

For us its useless that i need to give job specuial names to be able to filter it for rights mangemnt. It feels like a bad work around to manage security/acess aspects via the job name.
For multi tenacy i need conatiners(like folder's) inside jenkins i can manage per client the rights for all the jobs inside it, no mater whats in there.
It shall also be impossible to access the filesystem outside the workspace of this container. AT the moment every job can access all files accessable by the user who is running jenkins process (on the master), that is not acceptable from security perspective if you have one master managaging builds from different orgs. The actuala work around - have different jenkins servers for different clients - It's bad to maintain !
However we need to let different orgs let em manage their jobs (write config) and acceess each other jon's data inside the conatiner.

cforce: If you don't like the design of Role Strategy plugin, don't use it. It sounds like project-based matrix auth or the commercial Jenkins Enterprise plugin Role Based Access Control is a better fit for your needs. Besides, this has nothing to do with this issue or this plugin – maybe ask the jenkins-users mailing list for help instead?

Larger Jenkins instances also usually don't allow running any jobs on the master node. Just set up separate build nodes and only use the main Jenkins server as fancy UI and data storage. Then no builds have direct access to Jenkins config and data by escaping their $WORKSPACE.

Regarding isolation, Jenkins Enterprise offers some solutions here (e.g. Folders/Folders Plus plugins that allows restricting build nodes (slaves) to certain authorized project folders, so you can have org1-slave and org2-slave, and nobody configuring org1 jobs can get them to execute on org2-slave, isolating temporary workspaces).

Please also note that 'folders' has a specific meaning in this context and does not refer to file system directories:

http://jenkins-enterprise.cloudbees.com/docs/user-guide-bundle/folder.html
https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Free+Enterprise+Plugins#CloudBeesFreeEnterprisePlugins-FoldersPlugin

I've merged Jesse's PR into 1.1.3.
BTW, I haven't Jenkins Enterprise to check this version with Folders plugin.

I'm going to add support of Slaves/Nodes in 1.2.0 (https://github.com/jenkinsci/role-strategy-plugin/pull/3). Probably, I'll add support of views at the some point.

I haven't Jenkins Enterprise to check this version with Folders plugin.

Sigh, yes. If you wish to try it for yourself, you can download this plugin for free with a little hassle. We are aware of the difficulty in the de facto reference implementation of ItemGroup not being open source.

The Basic Folders plugin was made open source. https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Folders+Plugin You should be able to test this now without the need for the enterprise version.

Thanks for info.
Anyway, Jesse's fix is available in latest plugin's versions