Skip to content
This repository was archived by the owner on Apr 28, 2020. It is now read-only.

will not work on multi user systems #52

Closed
nhooyr opened this issue Apr 22, 2019 · 16 comments
Closed

will not work on multi user systems #52

nhooyr opened this issue Apr 22, 2019 · 16 comments

Comments

@nhooyr
Copy link
Contributor

nhooyr commented Apr 22, 2019

On any system where the user uid is not 1000, like macOS or multiple user systems, sail will be very slow due to the usermod -u step to adjust the uid inside the container to the one outside because it has to chown all files in the home folder.

I do not have a good solution for this.

See #51

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 22, 2019

Its only like a 5s delay so not crazy but still.

@nhooyr nhooyr mentioned this issue Apr 22, 2019
@ammario
Copy link
Member

ammario commented Apr 25, 2019

If we're indiscriminately chmoding home, isn't it possible we override some intentionally set permissions?

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

We're chowning it which should be fine.

@ammario
Copy link
Member

ammario commented Apr 25, 2019

Is that because chown doesn't propogate a mac mount? Confused

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

Its extremely unlikely any of the mounts contain files owned by a different user.

an alternative approach we could take is to pass in the UID to the build container as a build arg so that the image itself has the right uid from the get go.

@ammario
Copy link
Member

ammario commented Apr 25, 2019

In the rare case there is, there can be some minor corruption. E.g, what if they sshfs a server to some directory in home? I know i've done that before.. This could infinitely traverse my remote server and fuck me up good.

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

Just read the manpage, it turns out it only chowns files already owned by the user. Not sure how this interacts with mounts though. I'll give it a test.

@ammario
Copy link
Member

ammario commented Apr 25, 2019

That doesn't make any sense... If the file is already owned by the user what good does chowning it to the same user do?

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

Files aren't owned by the user, they're owned by the UID.

@ammario
Copy link
Member

ammario commented Apr 25, 2019

isn't the uid 1:1 associated with user

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

Yes, but if you change the UID for a user, you need to chown every file such thats its owned by the new UID.

nhooyr added a commit that referenced this issue Apr 25, 2019
Updates #52

Still no good support for multi user systems but I think that's fine
for now.
nhooyr added a commit that referenced this issue Apr 25, 2019
Updates #52

Still no good support for multi user systems but I think that's fine
for now.
@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

So turns out, the osxfs driver does the right thing by default: https://stackoverflow.com/questions/43097341/docker-on-macosx-does-not-translate-file-ownership-correctly-in-volumes

@nhooyr
Copy link
Contributor Author

nhooyr commented Apr 25, 2019

So multi user systems are supported on macOS without any changes. Just linux that will end up being an issue.

nhooyr added a commit that referenced this issue Apr 25, 2019
Updates #52

Still no good support for linux multi user systems but I think that's fine
for now.
nhooyr added a commit that referenced this issue Apr 25, 2019
Updates #52

Still no good support for multi user linux systems.
nhooyr added a commit that referenced this issue Apr 25, 2019
Updates #52

Still no good support for multi user linux systems.
@nhooyr nhooyr changed the title slow on macOS and multi user systems will not work on multi user systems Apr 29, 2019
@nhooyr
Copy link
Contributor Author

nhooyr commented May 3, 2019

@nathanpotter
Copy link
Contributor

Using that fixuid library to get CI working, seems to work pretty well

@nhooyr
Copy link
Contributor Author

nhooyr commented Nov 22, 2019

Going to close as it has been a while and I'm not sure if this is relevant anymore.

@nhooyr nhooyr closed this as completed Nov 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants