Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect ownership on files #211

Open
getninjaN opened this issue Nov 9, 2016 · 3 comments
Open

Incorrect ownership on files #211

getninjaN opened this issue Nov 9, 2016 · 3 comments
Labels

Comments

@getninjaN
Copy link

Bug Reports

Migrations, models and controllers created in a Rails application gets ownership root:staff on the host.

  • dlite version in use (run dlite --version):
    2.0.0-beta8

  • expected behavior:
    Files created should get the same ownership as the user running the command, e.g. [user]:staff.

  • actual behavior:
    Files created gets the ownership root:staff.

  • steps to reproduce

$ docker-compose run web rails g migration add_column_to_table
$ ls -la db/migrate
@nlf
Copy link
Owner

nlf commented Nov 11, 2016

yup, i know. this is a tough one to solve in a way that doesn't destroy performance. i have some ideas, but nothing solid yet.

i'll keep this issue open as a place for people to discuss any ideas they may have for this.

@gherkins
Copy link

you'd experience this problem when running docker in any kind of VM, right?

i also found dealing with permission conflicts between webserver- and cli-user also kind of difficult when working with docker containers in general.

we use a workaround for our php/symfony projects.
set the container webserver user (www-data) id to the host user id (id -u, 501 for mac os default user) and log in the container as www-data when executing CLI commands.

https://github.com/nerdpress-org/docker-sf3/blob/master/docker/docker.sh#L25
https://github.com/nerdpress-org/docker-sf3/blob/master/docker/apache-php/Dockerfile.dist#L50

while that works pretty solid across operating systems in our team (ubuntu,win,osx),
it's still a rather complex workaround.

would really appreciate some solution for that :) 👍

@nlf
Copy link
Owner

nlf commented Nov 15, 2016

yeah this is a problem that's not at all exclusive to dlite, mapping user ids between filesystems and hosts is a pain.

your workaround is arguably the correct solution. if the user ids match up, then you don't have any mapping to worry about and everything just works. obviously there's still the problem that the majority of docker containers still run services as root, and you can't change root's user id, but if you have control of all of your containers then that's not a big deal.

as for an actual fix, i'm working on a couple of things, but i'm not super encouraged about having a good way to fix this without causing major slow downs. there are only two ways to do this properly, both involve creating a wrapper around the filesystem. you can do that with FUSE, which is done at the userspace level and is actually pretty easy, but is VERY slow and we'd take a roughly 75% performance hit, or you can do it at the kernel level which is much much more difficult but would be a really minor performance penalty.

unfortunately, as of right now, writing this at the kernel level is a bit over my head. i'm doing some research to see if i can figure it out, but honestly i don't have real high hopes. the FUSE solution is pretty easy to implement, but i don't like the performance penalty.

if anyone here has experience with filesystems in the linux kernel, let's talk :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants