-
Notifications
You must be signed in to change notification settings - Fork 353
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
Feature request: package should be able to ask for less sandboxing #4674
Comments
I am pretty concerned about fast-tracks to disable security features in general; especially if they can be specified at the same place where the security issue might come from. With this in mind, in lack of a better solution, I would be in favour of a command-line option Now side-stepping the feature request per se, and focusing on the However, I am not sure that this is actually the case for I will look at Another track could be to check the minimal set of permissions |
pgocaml infers the types of SQL expressions by connecting to a server which a database with the required schema and preparing those statements against that database (preparing types the statement, but doesn't execute it). It does also have mechanisms for making changes while doing that (for example, if you create temporary tables then you need to do that at compile-time in order to infer the types for Two other points, though: the opam sandbox scripts don't at present restrict network access, so this can be solved (as you would likely be doing on Windows anyway) by using a TCP port on loopback to communicate with pgsql. It should also be possible to configure a Unix socket in the switch. |
I am strongly against any mechanism which would allow something within the sandbox to turn off the protection afforded by the sandbox. This would be an obvious way for any chained exploit to trivially bypass our protections. opam does allow filesystem read access and network access as @dra27 notes -- either of those should be sufficient to solve the pgocaml usecase described in the original report. |
The mechanism is not _within the sandbox, it is a declaration in the opam file, so that
Are you implying that, if a package can silently read my |
It is absolutely is within the sandbox - the package is what you're about to run within the sandbox and so reading anything from the package which tells/advises you to turn off the sandbox is within the sandbox. The The sandbox is intentionally course-grained and difficult to disable. If you start prompting the user, what then happens for unattended scripts? A non-interactive prompt now automatically answers yes to sandbox disabling? 😱 Let's not forget that the reason the sandbox was added is literally because a package author made a mistake, and quite a few people lost files... |
The whole point of opam is to make it easy for developers to share their work, and for newbies or external users to be able to use packages easily. All what you are saying goes against those principles. I am not saying my solution is the best or the only one, but asking the user to change the system or the switch is clearly not the good way to go. Neither is putting more burden on the developer, to understand how to turn automatically generated files by dune and ppxs into source files... Moreover, the proposed feature is generic, it would be useful for
Haha, who said disabling sandboxing would be the default ? There could be a lot of ways to make unattended scripts work perfectly, either by configuring opam or even the switch with a list of packages that are allowed to disable sandboxing... or not.
Currently, we have to ask our users to completely disable sandboxing in opam configuration, for all packages, to be able to install these packages. So, they are actually taking a higher risk that the one they would take by accepting to disable it only for one or two packages. |
I apologise if I'm misunderstanding this, but rather than developers understand their build system and alter the package to work in harmony with the sandbox, opam should add a feature which allows the package just to switch off the sandbox?
A feature being generic does not say anything about its merit. I'm not convinced (also being a PGO'Caml user) that this is useful for using pgocaml today. I'm curious to know how these packages are using postgres without any configuration requirement at the moment apart from disabling the sandbox - is it possible to see them? |
Yes. I have always been on the side of making the gap as small as possible for developers to adopt OCaml. And We are not discussing about switching off the sandbox for all packages. Just to provide a simple and safer way to do it when it is needed.
Do you have an opam package for your own work on PGOCaml ? Maybe it will help me solve my problem if this feature is not added...
Yes, of course: If you try to build |
The original issue's fixed, so closing this one for now. |
Some packages, like pgocaml and other packages depending on pgocaml, require to have access to external services. In the case of pgocaml and its children, it needs to be able to connect to the local PostgresQL database (either unix socket or localhost in read/write mode) to check the correctness ocaml types with regards to db schemas. Since sandboxing prevents such accesses, using opam to distribute executables depending on pgocaml is difficult, you must explain to the user how he should disable sandboxing and re-enable it afterwards, and to do that everytime the switch is updated. It would be much better if such packages could ask for permission to disable sandboxing, and opam would prompt the user to ask if he is ok with it or not for the given packages.
It comes with multiple benefits:
--disable-sandboxing-for=pgocaml
, to make it automaticallyOf course, given that sandboxing is currently performed through hooks, an early solution would be to disable hooks instead of disabling sandboxing. So a package would just add:
(it would also disable opam-bin, but that's fair, because opam-bin is not supposed to work on packages performing side-effects on the system).
The text was updated successfully, but these errors were encountered: