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

Handle symlinks in bwrap #3661

Merged
merged 1 commit into from Nov 9, 2018

Conversation

Projects
None yet
2 participants
@mroch
Copy link
Contributor

mroch commented Nov 6, 2018

On some OSes, like CentOS and Arch Linux (so I've read), /bin is a symlink to /usr/bin, /lib is a symlink to /usr/lib, etc.

Mounting them directly with --ro-bind resolves the symlinks. This breaks paths like /bin/../libexec: when /bin is a symlink to /usr/bin, /bin/../libexec points to /usr/libexec; but if it gets resolved first, it points to /libexec.

Fixes #3660

Handle symlinks in bwrap
On some OSes, like CentOS and Arch Linux (so I've read), `/bin` is a symlink to `/usr/bin`, `/lib` is a symlink to `/usr/lib`, etc. 

Mounting them directly with `--ro-bind` resolves the symlinks. This breaks paths like `/bin/../libexec`: when `/bin` is a symlink to `/usr/bin`, `/bin/../libexec` points to `/usr/libexec`; but if it gets resolved first, it points to `/libexec`.

Fixes #3660
@rjbou

This comment has been minimized.

Copy link
Collaborator

rjbou commented Nov 8, 2018

Thanks for the contribution!
There is a case that is not handled: if resolved symlink is not contained in mounted directories list. But I'm not even sure that it can happen on a usual state, and mounting them automatically could result to a breach. Environment variable OPAM_USER_RO_PATH can be used for that special case...

@mroch

This comment has been minimized.

Copy link
Contributor

mroch commented Nov 8, 2018

yeah, i suppose that could happen but I think this might actually be a desirable behavior change in that case. previously, if /bin was a symlink to /malicious, /malicious would get mounted. now it'd be a broken symlink and you'd have to explicitly add /malicious.

but I also scoped it to just the system paths with the assumption that those are not likely to point unusual/dangerous places.

@rjbou rjbou merged commit a5cb01c into ocaml:master Nov 9, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

rjbou added a commit to rjbou/opam that referenced this pull request Dec 6, 2018

Handle symlinks in bwrap (ocaml#3661)
On some OSes, like CentOS and Arch Linux (so I've read), `/bin` is a symlink to `/usr/bin`, `/lib` is a symlink to `/usr/lib`, etc. 

Mounting them directly with `--ro-bind` resolves the symlinks. This breaks paths like `/bin/../libexec`: when `/bin` is a symlink to `/usr/bin`, `/bin/../libexec` points to `/usr/libexec`; but if it gets resolved first, it points to `/libexec`.

Fixes ocaml#3660
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment