Docs: Clarify that -I is not a security boundary#150790
Docs: Clarify that -I is not a security boundary#150790StanFromIreland wants to merge 3 commits into
-I is not a security boundary#150790Conversation
Documentation build overview
76 files changed ·
|
Co-authored-by: Bartosz Sławecki <bartosz@ilikepython.com>
|
@zooba, any thoughts here? |
|
@vstinner, I removed the note you added to 'Security Considerations,' since these flags aren't guaranteed to be security boundaries, I don't think we should imply that by putting them there. |
| :envvar:`PYTHONPATH` and :envvar:`PYTHONHOME`, that might be set. | ||
| This is useful for running commands that should not take into account the | ||
| user's current environment settings, but does not necessarily mean that the | ||
| current environment will have no effect. |
There was a problem hiding this comment.
I'm not sure that this sentence is useful. In the first sentence, the effect of the option is well defined: "Ignore all PYTHON* environment variables" (nothing more, nothing less). In the second sentence, "User's current environment" is a little bit vague to me. Does it mean that variables which don't start with PYTHON are also ignored? No, they are not ignored.
| In isolated mode :data:`sys.path` contains neither the script's directory nor | ||
| the user's site-packages directory. All ``PYTHON*`` environment | ||
| variables are ignored, too. Further restrictions may be imposed to prevent | ||
| the user from injecting malicious code. |
There was a problem hiding this comment.
In the REPL, import readline is omitted in isolated mode. That's what the last sentence implies indirectly.
| variables are ignored, too. Further restrictions may be imposed to prevent | ||
| the user from injecting malicious code. | ||
| variables are ignored, too. This feature is not a security boundary. | ||
| Further restrictions need to be imposed to prevent the user from injecting |
There was a problem hiding this comment.
I didn't know the "security boundary" expression. What does it mean? I don't think that security is a all-or-nothing thing, it's more complicated.
| empty string, which means the current working directory. | ||
|
|
||
| This feature is not a security boundary. Further restrictions need to be | ||
| imposed to prevent the user from injecting malicious code. |
There was a problem hiding this comment.
I don't think that the current -P option documentation implies that it protects you from any malicious code injection. I don't see the value of adding this paragraph. It doesn't explain how to block all entry points for malicious code.
| mode. When it cannot be used, the :option:`-P` option or the | ||
| :envvar:`PYTHONSAFEPATH` environment variable can be used to not prepend a | ||
| potentially unsafe path to :data:`sys.path` such as the current directory, the | ||
| script's directory or an empty string. |
There was a problem hiding this comment.
I removed the note you added to 'Security Considerations,' since these flags aren't guaranteed to be security boundaries, I don't think we should imply that by putting them there.
This paragraph explains how to harden Python command line interface, to protect against some issues. It doesn't imply that it protects from all possible attacks.
I would prefer to keep the paragraph here. If you consider that the intent of this paragraph is unclear, I suggest rephrasing it, and maybe explain somehow what are all ways to inject code, and what are means to harden Python.
No description provided.