How to lift an app out of it's sandbox into deployment?

[Chris]

Hello

I face the following issue using gocd, with my gocd agent:

My app is containerized [docker] and needs to log via bind mount. The app cannot log in the sandbox, as it does not have permissions to the log directory.

I would like the app to be copied out from the sandbox, into /home/ubuntu/app , where it would have permissions to write to it's log directory.

Nothing has worked out so far, including trying to force permissions to 777 to the directory, and I always get the following error message:

cp: failed to access '/home/ubuntu/app': Permission denied
deployment/dev/deploy.sh: line 2: cd: /home/ubuntu/app: Permission denied

Deploy script:
cp -r app/. /home/ubuntu/app
cd /home/ubuntu/app
make start

Thank you!

[Jason Smyth]

Hello Chris,

This appears to be a permissions issue rather than anything specific to GoCD.

I recommend logging on to the Agent and manually running the script as the GoCD user (via sudo or su). From there you should be able to troubleshoot the permissions error.

Once the script runs properly when run locally on the Agent, the Pipeline should also run without issue.

Hope this helps,

Jason Smyth

[Chris]

I changed the user and group ownership of /home/ubuntu/app to go, although 777 should have sufficed for testing purposes.

When I su to user go, I am able to view /home/ubuntu/app, and also touch foo.txt in /home/ubuntu/app . I

go@app:/home/ubuntu$ cd app
go@app:/home/ubuntu/app$ touch foo.txt
go@test-app:/home/ubuntu/app$ ls -la
total 8
drwxr-xr-x 2 go     go     4096 Jun 29 20:10 .
drwxr-x--- 7 ubuntu ubuntu 4096 Jun 29 20:09 ..
-rw-rw-r-- 1 go     go        0 Jun 29 20:10 foo.txt
go@app:/home/ubuntu/app$ rm foo.txt
go@app:/home/ubuntu/app$ exit

Go agent is running as go:
go           634  0.0  0.2  16452  2464 ?        Sl   Jun24   4:09 /usr/share/go-agent/bin/.

The go agent is still unable to copy a file into /home/ubuntu/app   , or even cd into /home/ubuntu/app  , with any level of permission (777, changing it to go, etc)

[Ketan Padegaonkar]

This will almost certainly not fly. /home/ubuntu will also need permission change. Adding a world writeable permission 777 is a very bad idea. I would recommend that you add the go user to the same group as the ubuntu user, and make sure the deployment folder has write permission for the ubuntu group.

As ubuntu user:

- rm -rf /home/ubuntu/app

- mkdir /home/ubuntu/app

- chmod g=u /home/ubuntu/app # group has same permission as user

As root:

- usermod -a -G ubuntu go # add go user to ubuntu

- restart your go agent

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/751e5c97-596a-4441-bbb7-07c5aa9c314dn%40googlegroups.com.

[Jason Smyth]

Hi Chris,

Ketan raises a good point: with the current permissions, the go user has no access to /home/ubuntu, unless it is already a member of the ubuntu group.

The steps he provided should address the permissions issue, but after re-reading the initial problem statement, maybe "How to get an Agent process out of its sandbox?" is not the right question to ask. Maybe the question should be "How to grant the application running in its container permissions to write to the sandbox directory?"

Something like this in the deployment script might work:

cd app

chmod o+w ./path/to/log/dir # make sure container can write to log directory

make start

This could be considered a security risk since it makes the log directory writable by any user, but the sandbox itself is protected because /var/lib/agent restricts access to the go user and go group (mode 750). The container would bypass this limitation by directly mounting the writable directory to its local file system.

If this works, it provides the additional benefit that it does not introduce any new requirements to the Agent environment. This helps keep the process decoupled from the runtime environment.

Hope this helps,

Jason Smyth

[Chris]

Thanks for the assistance. The issue was as described by Ketan, even though I had added user 'go' to group 'ubuntu', I did not restart the go agent, so the running process was still considered to not be a member of the ubuntu group, despite the fact the user could see and modify files in the app directory.

Best,

Chris