<p>There is currently no ability to restrict jobs which are able to run on the same agent from potentially interacting with each other. There are a bunch of feature requests asking for this sort of granularity, but if I understand your question correctly the most fitting request would be this one <a href="https://jira.atlassian.com/browse/BAM-2504" rel="noreferrer" title="BAM-2504">BAM-2504 Jira Ticket</a></p>

<p>It's a huge gap in the product line, the only solution I've found is similar to what is proposed by the request linked above, essentially your bamboo process would need to run with sufficient privileges to impersonate a set of users who represent the projects which you would like to keep separate. </p>

<p>Once you have this sort of mechanism in place you just need to try to enforce that all plans run as one of the impersonatable accounts, depending for example on the project or the creator etc.</p>

<p>Problematically the way that access controls currently exist this would mean that few core admins would need to set up all the plans so that they can he sure of the required permissions split rather than letting non-administrative users edit and create their own plans.</p>

<p>If this sort of approach isnt feasible, which it isn't once you get into the "many hundreds of users" type of range, then the only thing you can really do to try and stop build jobs from interacting with each other is implement the very weak controls that bamboo gives you.</p>

<p>I've tried two approaches to doing this:</p>

<ol>
<li>Delete or cripple (remove all capabilities from) your local agents and for every different project/team/whatever that on boards to your bamboo instance you need to force them to BYO build server. In most instances I've been involved in the cost of an agent is utterly trivial compared to the cost of potential data leakage or malicious plan interactions.</li>
<li>Make sure that projects that do have, or that think they do have, sensitive data involved in their plans always sanitise their environments after they build. This shifts the burden off the team administering the tools and onto the projects writing their plans and forces them to defensively clean up any information that they don't want potentially available to others.</li>
</ol>

<p>Neither solution is even close to perfect but to the best of my knowledge that's about as much separation as you can enforce if you have a shared bamboo instance.</p>

CC BY-SA 3.0
2017-03-17T17:28:55.800Z
2017-03-17T17:28:55.800Z
hvindin
<p>We have Atlassian Bamboo running on Ubuntu. When a developer is setting up a build, then he or she has the possibility to run shell script tasks. This is useful to run (custom) commands on the codebase you are building.</p>

<p>However, the scripts that run can also access the filesystem outside their job directory in the Bamboo working directory (<code>&lt;Bamboo-home-dir&gt;/xml-data/build-dir/JOB_KEY</code>). So JOB_A can also access files of JOB_B: <code>cd ../JOB_B</code>.</p>

<p>Is there a possibility to restrict this access?</p>

<p>P.S. I am aware of the fact that builds are ran by (local or remote) agents in Bamboo and you can build different projects by different agents. However, if two projects are built by the same agent, the projects could access each other's files.</p>

<builds><bamboo><permissions>
How to restrict filesystem access in Atlassian Bamboo builds?
7ochem
# How to restrict filesystem access in Atlassian Bamboo builds?

(Asked by: username_0 on 2017-03-16)

We have Atlassian Bamboo running on Ubuntu. When a developer is setting up a build, then he or she has the possibility to run shell script tasks. This is useful to run (custom) commands on the codebase you are building.

However, the scripts that run can also access the filesystem outside their job directory in the Bamboo working directory (`/xml-data/build-dir/JOB_KEY`). So JOB\_A can also access files of JOB\_B: `cd ../JOB_B`.

Is there a possibility to restrict this access?

P.S. I am aware of the fact that builds are ran by (local or remote) agents in Bamboo and you can build different projects by different agents. However, if two projects are built by the same agent, the projects could access each other's files.

**Tags:** builds, bamboo, permissions


---

## 1 answers

### Answer by username_1 on 2017-03-17. Score: 9 | Accepted answer

There is currently no ability to restrict jobs which are able to run on the same agent from potentially interacting with each other. There are a bunch of feature requests asking for this sort of granularity, but if I understand your question correctly the most fitting request would be this one [BAM-2504 Jira Ticket](https://jira.atlassian.com/browse/BAM-2504 "BAM-2504")

It's a huge gap in the product line, the only solution I've found is similar to what is proposed by the request linked above, essentially your bamboo process would need to run with sufficient privileges to impersonate a set of users who represent the projects which you would like to keep separate.

Once you have this sort of mechanism in place you just need to try to enforce that all plans run as one of the impersonatable accounts, depending for example on the project or the creator etc.

Problematically the way that access controls currently exist this would mean that few core admins would need to set up all the plans so that they can he sure of the required permissions split rather than letting non-administrative users edit and create their own plans.

If this sort of approach isnt feasible, which it isn't once you get into the "many hundreds of users" type of range, then the only thing you can really do to try and stop build jobs from interacting with each other is implement the very weak controls that bamboo gives you.

I've tried two approaches to doing this:

1. Delete or cripple (remove all capabilities from) your local agents and for every different project/team/whatever that on boards to your bamboo instance you need to force them to BYO build server. In most instances I've been involved in the cost of an agent is utterly trivial compared to the cost of potential data leakage or malicious plan interactions.
2. Make sure that projects that do have, or that think they do have, sensitive data involved in their plans always sanitise their environments after they build. This shifts the burden off the team administering the tools and onto the projects writing their plans and forces them to defensively clean up any information that they don't want potentially available to others.

Neither solution is even close to perfect but to the best of my knowledge that's about as much separation as you can enforce if you have a shared bamboo instance.


---

