Non root user "breaks" dokku-volume

[michaelshobbs]

Wasn't sure where this should go, so I'm starting here.

When the non-root user feature came to be, /exec was modified to chown -R <user>:<group> /app but we do not have a way to extend this behavior to other mounted volumes in dokku (and I assume any other extension of buildstep)...

example:

1. install dokku
2. install https://github.com/ohardy/dokku-volume

root@dokku:~/dokku# dokku volume:add app /myappcache
root@dokku:~/dokku# dokku run app bash
u22374@0e95e1326e0c:~$ ls -lad /myappcache
drwxr-xr-x 2 1002 1002 4096 Feb 10 16:50 /myappcache
u22374@0e95e1326e0c:~$ touch /myappcache/foo
touch: cannot touch '/myappcache/foo': Permission denied

Should this be solved once in buildstep vs. several times throughout the plugin community or is this out of scope?

Currently dokku-logging-supervisord implemented a solution like this.

# Change ownership of /var/log/app to non-root container user
APP_USER=$(stat -c %U /app)
APP_GROUP=$(stat -c %G /app)
if [[ -n "$APP_USER" ]] && [[ -n "$APP_GROUP" ]]; then
  chown -R "${APP_USER}:${APP_GROUP}" /var/log/app
  chmod -R g+rw /var/log/app
fi

Just to throw an initial spitball out, what if plugins set/update a config variable that is a list of container paths and /exec chowns those as well?

[progrium]

Yeah this is interesting. My initial reaction is it should be solved in
Dokku ... but also that it should be solved with as minimal a solution as
possible. For example, dokku-volumes requiring and/or ensuring all users
have read-write access to volumes.

On Tue, Feb 10, 2015 at 11:08 AM, Michael Hobbs notifications@github.com
wrote:

Wasn't sure where this should go, so I'm starting here.

When the non-root user feature came to be, /exec was modified to chown -R
: /app but we do not have a way to extend this behavior to
other mounted volumes in dokku (and I assume any other extension of
buildstep)...

example:

1. install dokku
2. install https://github.com/ohardy/dokku-volume

root@dokku:/dokku# dokku volume:add app /myappcache
root@dokku:/dokku# dokku run app bash
u22374@0e95e1326e0c:$ ls -lad /myappcache
drwxr-xr-x 2 1002 1002 4096 Feb 10 16:50 /myappcache
u22374@0e95e1326e0c:$ touch /myappcache/foo
touch: cannot touch '/myappcache/foo': Permission denied

Should this be solved once in buildstep vs. several times throughout the
plugin community or is this out of scope?

Currently dokku-logging-supervisord implemented a solution like this.

Change ownership of /var/log/app to non-root container user

APP_USER=$(stat -c %U /app)
APP_GROUP=$(stat -c %G /app)
if [[ -n "$APP_USER" ]] && [[ -n "$APP_GROUP" ]]; then
chown -R "${APP_USER}:${APP_GROUP}" /var/log/app
chmod -R g+rw /var/log/app
fi

Just to throw an initial spitball out, what if plugins set/update a config
variable that is a list of container paths and /exec chowns those as
well?

—
Reply to this email directly or view it on GitHub
#133.

Jeff Lindsay
http://progrium.com

[michaelshobbs]

I definitely agree in principle. On a more meta level, I'm not sure how to allow container RW access to a volume without opening it up to all users since the container user doesn't map to a host user....

[michaelshobbs]

An idea from IRC...what if buildstep (/exec) exported the user and group?

[progrium]

Exported how?

On Tue, Feb 10, 2015 at 11:33 AM, Michael Hobbs notifications@github.com
wrote:

An idea from IRC...what if buildstep (/exec) exported the user and group?

—
Reply to this email directly or view it on GitHub
#133 (comment).

Jeff Lindsay
http://progrium.com

[michaelshobbs]

Though I suppose the stat method is sufficient.

[michaelshobbs]

If the accepted pattern is to run everything through /exec and it knows the user generated by the build process, then it could export $BUILDSTEP_USER and $BUILDSTEP_GROUP.

[progrium]

Oh I see. Interesting.

On Tue, Feb 10, 2015 at 11:39 AM, Michael Hobbs notifications@github.com
wrote:

If the accepted pattern is to run everything through /exec and it knows
the user generated by the build process, then it could export
$BUILDSTEP_USER and $BUILDSTEP_GROUP.

—
Reply to this email directly or view it on GitHub
#133 (comment).

Jeff Lindsay
http://progrium.com

[jaysh]

I feel it would be useful to have the ability to control the uid/gid within the container - in addition to the values being exported. I'm facing an issue whereby I would like to create a Data Volume container to share data between two containers, however I am facing two problems:

1. The users are not consistent across deployments. Therefore, if files are created in a volume and the application is redeployed, the ability to write more files can be lost (if e.g. the directory was owned by the previous deployment).
2. It makes it difficult (or impossible, without resorting to permission hacks) to share volumes between containers. This Stack Overflow answer has some good detail on ways to work around Docker limitations, but from my reading, the buildstep project would need to be changed to accommodate them.

[alessio]

I worked around the problem in dokku-volume with a horrible-hack: alessio/dokku-volume@d4a58b6

When you create a data volume for an app, the plugin creates the host's data directory with the dokku user as owner - that is not bad per se, afterwards the plugin didn't manage to make it writable for the container's user (is it a limitation of Docker? Dunno, it provides the '-v' option with the ':ro' flag to access data within containers read-only, however Docker's docs do never mention things like data volumes's ACLs) as the former doesn't know anything about the latter.

Shortly: FWIW I second @michaelshobbs's idea to export BUILDSTEP_{GROUP,USER}

Post-Scriptum: Once this is sorted, it would be great to see dokku taking the responsibility to handle data volumes rather than delegating to external plugins, but that is another story though.

[alessio]

Any progress on this?

[michaelshobbs]

@progrium bump. what's the new world view on this topic?