Sandbox missing functions like 'fcntl'
Hi! I am getting this error from the sandbox: Not Implemented: sandboxing for external function 'fcntl' I am using a custom controller process, and getting this in fdopen (pypy_interact bombs on something else before it gets to that point). After much digging, I think this is due to _check_fd_mode function in rpython/rlib/streamio.py. In sandbox mode, I think there is little use for this check, but since it's there, I need some workaround. Does anyone have recommendations? More generally, my team needs to decide if we can rely on the pypy sandbox to use in our product. It seems brilliantly designed, fast, and overall impressive. But there are these gaps in missing sandbox wrappers (there are others too, fcntl is just one that I don't know how to avoid). And I noticed some code that indicates that it is not supported on Windows -- is that the case? What are the sandbox's prospects, within the larger future of pypy? Dmitry
Here is a far more baffling one: Not Implemented: sandboxing for external function 'pypy_jit_depthmap_add' That's certainly not something I would expect the controller process to implement. It seems to happen after a bunch of repetitive commands (when I suppose JIT is kicking in). BTW, I did not run into either of these issues with a build from a year ago, around commit 72100. If anyone can suggest what I might be doing wrong, I would greatly appreciate. Dmitry On Mon, Jun 8, 2015 at 6:31 PM, Dmitry Sagalovskiy <dmitry@getgrist.com> wrote:
Hi!
I am getting this error from the sandbox:
Not Implemented: sandboxing for external function 'fcntl'
I am using a custom controller process, and getting this in fdopen (pypy_interact bombs on something else before it gets to that point). After much digging, I think this is due to _check_fd_mode function in rpython/rlib/streamio.py. In sandbox mode, I think there is little use for this check, but since it's there, I need some workaround. Does anyone have recommendations?
More generally, my team needs to decide if we can rely on the pypy sandbox to use in our product. It seems brilliantly designed, fast, and overall impressive. But there are these gaps in missing sandbox wrappers (there are others too, fcntl is just one that I don't know how to avoid). And I noticed some code that indicates that it is not supported on Windows -- is that the case?
What are the sandbox's prospects, within the larger future of pypy?
Dmitry
Hi Dmitry, On 9 June 2015 at 05:10, Dmitry Sagalovskiy <dmitry@getgrist.com> wrote:
More generally, my team needs to decide if we can rely on the pypy sandbox to use in our product. It seems brilliantly designed, fast, and overall impressive. But there are these gaps in missing sandbox wrappers (there are others too, fcntl is just one that I don't know how to avoid). And I noticed some code that indicates that it is not supported on Windows -- is that the case? What are the sandbox's prospects, within the larger future of pypy?
The sandbox code is there and "mostly working", but it is lacking a champion. It has been in this state for many years now (it is actually impressive that it still roughly works). Realistically, though, to answer the question of its prospects, it depends entirely on whether someone would be ready to become involved in PyPy and help maintain and develop it. As usual with Open Source, we can't predict when (and if) this will occur. From our point of view, it seems to attract occasional attention like yours, but we just have too many things to work on.
If anyone can suggest what I might be doing wrong, I would greatly appreciate.
You're not doing anything wrong, just stumbling on a mixture of old and new code. In the case of 'pypy_jit_depthmap_add', it's because we recently added vmprof support and didn't think about sandboxing. The fix is probably easy: we need a few "sandboxsafe=True" keyword arguments in rpython/jit/backend/llsupport/codemap.py. The issue with 'fcntl' is more obscure and involves much older code. In that case we need the sandboxed interpreter to ask the outside what to do---which should occur automatically, but doesn't, for reasons I'm still investigating. I suspect it's related to the XXX in the comment of select_function_code_generators() in rpython.translator.c.node. (I think with minimal effort we can finally get rid of the "oldstyle" functions mentioned there.) A bientôt, Armin.
Thank you for the explanation, Armin. It's as I thought. OK, then a brief announcement for potential sandbox champions on this list :) Our early-stage startup (Grist Labs <https://www.getgrist.com/jobs>) is looking for an engineer who can also be a pypy sandbox champion! Competitive salary, benefits, equity, plus the ability (and encouragement) to contribute to pypy. For the moment, we are only offering a full-time position in New York City, but if you have a strong interest elsewhere, let's talk anyway. I hope this isn't an abuse of this list, but really: the pypy sandbox is an important and promising tools for us. We'd like to contribute what we can. Dmitry On Tue, Jun 9, 2015 at 2:46 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Dmitry,
On 9 June 2015 at 05:10, Dmitry Sagalovskiy <dmitry@getgrist.com> wrote:
More generally, my team needs to decide if we can rely on the pypy sandbox to use in our product. It seems brilliantly designed, fast, and overall impressive. But there are these gaps in missing sandbox wrappers (there are others too, fcntl is just one that I don't know how to avoid). And I noticed some code that indicates that it is not supported on Windows -- is that the case? What are the sandbox's prospects, within the larger future of pypy?
The sandbox code is there and "mostly working", but it is lacking a champion. It has been in this state for many years now (it is actually impressive that it still roughly works). Realistically, though, to answer the question of its prospects, it depends entirely on whether someone would be ready to become involved in PyPy and help maintain and develop it. As usual with Open Source, we can't predict when (and if) this will occur. From our point of view, it seems to attract occasional attention like yours, but we just have too many things to work on.
If anyone can suggest what I might be doing wrong, I would greatly appreciate.
You're not doing anything wrong, just stumbling on a mixture of old and new code. In the case of 'pypy_jit_depthmap_add', it's because we recently added vmprof support and didn't think about sandboxing. The fix is probably easy: we need a few "sandboxsafe=True" keyword arguments in rpython/jit/backend/llsupport/codemap.py. The issue with 'fcntl' is more obscure and involves much older code. In that case we need the sandboxed interpreter to ask the outside what to do---which should occur automatically, but doesn't, for reasons I'm still investigating. I suspect it's related to the XXX in the comment of select_function_code_generators() in rpython.translator.c.node. (I think with minimal effort we can finally get rid of the "oldstyle" functions mentioned there.)
A bientôt,
Armin.
participants (2)
-
Armin Rigo
-
Dmitry Sagalovskiy