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

file permissions #40

Closed
snodnipper opened this issue Feb 7, 2017 · 3 comments
Closed

file permissions #40

snodnipper opened this issue Feb 7, 2017 · 3 comments

Comments

@snodnipper
Copy link
Contributor

I noted that when I used the whalebrew/wget package as a non-root user (e.g. ubuntu user in the docker group) that the files I downloaded had the permissions set to root.

ubuntu@ip-172-37-43-241:~/$ wget https://www.google.com/favicon.ico
ubuntu@ip-172-37-43-241:~/$ ls -al
-rw-r--r-- 1 root root     5430 Dec  8 01:00 favicon.ico

I have amended the code to use the user's id and primary group id but I guess this could be something for further consideration.

ubuntu@ip-172-37-43-241:~/$ wget https://www.google.com/favicon.ico
ubuntu@ip-172-37-43-241:~/$ ls -al
-rw-r--r-- 1 ubuntu ubuntu     5430 Dec  8 01:00 favicon.ico

I can certainly raise a PR but the thoughts of others might be useful first.

snodnipper@6b06198
@jskeates

@snodnipper snodnipper changed the title wget file permissions file permissions Feb 7, 2017
@bfirsh
Copy link
Member

bfirsh commented Feb 7, 2017

Thanks @snodnipper! This is a dupe of #11.

The problem with the approach of passing -u to docker run, I think, is it means the permissions of files inside the container that the process needs to access may be wrong. (e.g. it might expect a file owned by root to be writable). I think it could work as an interim solution, though, because I think the problem you describe is worse and more common than the problem of not being able to access files inside the container. Feel free to open as a PR and perhaps we can discuss around that.

I have outlined what I think is a correct long-term solution in #11.

@gutierri
Copy link

@bfirsh the problem was solved with path #42 ? Close issue?

@snodnipper
Copy link
Contributor Author

Closed as far as I am concerned. Thank you for the reminder.

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

No branches or pull requests

3 participants