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

FR: Allow for EACCES when enforceSourceReadsUnderPackageRoots is used #1345

Open
evancharlton opened this issue Jan 15, 2025 · 1 comment
Open

Comments

@evancharlton
Copy link

A common pattern is to have tools walk up the directory hierarchy and collapse parent configurations. Example packages which do this: eslint, cosmiconfig. However, when enforceSourceReadsUnderPackageRoots is used in BuildXL, this is a bit annoying - it requires that the developer find each package's method to stop traversals (eg, root: true in eslint's config).

These tools generally1 handle EACCES errors well, and use that as a signal to stop traversals. Could BuildXL add support for preventing read access, rather than failing the build?

This is related to an open feature request in the esbuild project: evanw/esbuild#4036 - this tool doesn't provide any way to stop the directory traversal, and instead relies on EACCES errors being thrown.

Footnotes

  1. I have not conducted a thorough audit of the ecosystem; this is just based on my experience and a light skimming of the source code of several packages.

@smera
Copy link
Member

smera commented Jan 17, 2025

The BuildXL sandbox doesn't really have a good way to prevent a read access. On one hand, we can alter the way an access is being done only in certain circumstances (we use libc interpose for most cases, but we fallback to a strace-based sandbox in some others, and the latter only allows for observing accesses). But in general, we try to stay away from altering syscalls. The consequences of altering a syscall are always pretty hard to predict, and keeping consistency with other syscalls is also challenging. I think every time we tried, we always ended up regretting it.
But even if we could, the end result will probably be some configuration knob where users need to specify this behavior in some way. So probably not too different than the current approach, where the access has to be allowlisted with an explicit configuration.

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

2 participants