separating security messages

[jsmith173]

Is it possible to seperate security messages?
It seems RestrictedPython uses existing exception types to report a security error.

I have found in compile.py

if result.errors:
raise SyntaxError(result.errors)`

When I replace SyntaxError to my new exception type it will solve the problem? Or how could I do that?

[icemac]

We could create a custom subclass of the existing exception classes, because a SyntaxError should stay one to prevent problems with existing code expecting a Python SyntaxError.

[icemac]

A PR is welcome.

[d-maurer]

Michael Howitz wrote at 2024-3-27 23:53 -0700:

We could create a custom subclass of the existing exception classes, because a `SyntaxError` should stay one to prevent problems with existing code expecting a Python `SyntaxError`.

I do not see a need for a change -- especially not for `SyntaxError`: An application could know whether it has used `compile` or `compile_restricted` and therefore whether it sees an unrestricted or a restricted `SyntaxError`.

[jsmith173]

When I handle 'SyntaxError' in the app how could I check, it is a real syntax error or it is a security exception? Also sometimes security error messages come from 'exec'

[d-maurer]

jsmith173 wrote at 2024-3-28 01:08 -0700:

When I handle 'SyntaxError' in the app how could I check, it is a real syntax error or it is a security exception? Also sometimes security error messages come from 'exec'

I have searched the `RestrictedPython` sources: there is a single place where `RestrictedPython` itself raises a `SyntaxError`: at the end of `RestrictedPython.compile.compile_restricted`. You have several options to distinguish this use of `SyntaxError` from the "normal" ones: * You can use your own `compile_restricted` which uses a different exception * You can use `dm.reuse.rebind_function` to bind the `SyntaxError` reference in `compile_restricted` to an exception of your choice. * You can look at the `args` attribute of the `SyntaxError`. When the `SyntaxError` was raised by `Python`, `args` appears to have more than a single element and the first one is a string; when `compile_restricted` raises `SyntaxError`, it is called with `result.errors` which gives a single element in `args` almost surely of type `list`. Regarding exceptions from `exec` In a previous comment, I have sketched how `RestrictedPython` works: it transforms the Python source code to implement standard Python features (especially attribute access and subscription) to function calls. This gives an application control over those features by implementing those functions as it needs them. Thus, if you do not like the exceptions raised by some implementation functions provided by `RestrictedPython`, you replace those functions by your own implementation which raises the exceptions you like. You can search the `RestrictedPython` sources for `Error` (as word part) to learn which exceptions `RestrictedPython` uses and which parts you may want to replace by your own implementation functions.

[jsmith173]

compile_restricted collects the real syntax errors so even if I have a new exception I will have real syntax errors in that.

[d-maurer]

jsmith173 wrote at 2024-3-28 03:50 -0700:

compile_restricted collects the real syntax errors so even if I have a new exception I will have real syntax errors in that.

Do you tell me that `result.errors` (at the end of `compile_restricted`) contains (only) the real syntax errors collected by `RestrictedPython`? If this is the case, why would you be unhappy? In my previous comment, I told you how you would be able to distinguish `SyntaxError`s generated by Python from the raised by `compile_restricted`. What else do you need?

[ScrambledRK]

Thank you d-maurer for the insight and ideas.

Quite clever, but they all smell like a workaround to me.
Maybe I'm just too stiff and conservative.

I don't think its a good idea to rebind or rewrite parts of a library that is so clearly related to security. I do not want to open any more opportunities for mistakes and risks than I already do using the library in the first place. Relying on the number of elements args contains seems bold to me. I rather not rely on something that only "appears" to be so. Dunno, I rather not differentiate then at all. At the cost of worse user feedback.

In my case I'd like to ...
a) inform the user that what they are trying to do is usually okay, but not in my environment
b) use it in tests to exclude accidental test passes due to actual syntax errors in the test code

Since I am just prototyping and experimenting for now, my need for this feature is very low.
But the "accepting PR" is noted x)

[loechel]

@ScrambleRK and @d-maurer when I see it correctly the SyntaxError in https://github.com/zopefoundation/RestrictedPython/blob/master/src/RestrictedPython/compile.py#L211 is the only one that is raised by RestrictedPython itself. As it just lists all collected errors I wonder if SyntaxError is the correct Error or Exception for this use case.

As RestrictedPython is a restricted sub set of Python, everything that raises a real SyntaxError is really a Syntax Error found by the AST Module or the internal interpreter. All Restrictions should be collected in another way and should be announced in a different way.

If we change this one line of code and introduce a new Exception / Error Class that would be a breaking change and needs a new major version.
@icemac any comments?

[icemac]

@loechel Changing the SyntaxError we raise to a subclass of SyntaxError would make the problem for the consumers of RestictedPython a bit less problematic as at least the isinstance tests still work. But I'd still consider this a major change.