On Tue, 2 Sep 2014 00:53:11 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: > On 2 Sep 2014 00:08, "Antoine Pitrou" <solipsis at pitrou.net> wrote: > > > > On Mon, 1 Sep 2014 23:42:10 +1000 > > Chris Angelico <rosuav at gmail.com> wrote: > > > >> > > > >> That has to be done inside the same process. But imagine this > > > >> scenario: You have a program that gets invoked as root (or some other > > > >> user than yourself), and you're trying to fiddle with what it sees. > > > >> You don't have root access, but you can manipulate the file system, > to > > > >> the extent that your userid has access. What can you do to affect > this > > > >> other program? > > > > > > > > If you're root you shouldn't run untrusted code. See > > > > https://docs.python.org/3/using/cmdline.html#cmdoption-I > > > > > > Right, which is why sslcustomize has to be controlled by that, but the > > > possibility of patching (or monkeypatching) ssl.py isn't as big a > > > deal. > > > > To be frank I don't understand what you're arguing about. > > When I said "shadowing ssl can be tricky to arrange", Chris correctly > interpreted it as referring to the filesystem based privilege escalation > scenario that isolated mode handles, not to normal in-process > monkeypatching or module injection. There's no actual difference. You can have a sitecustomize.py that does the monkeypatching or the shadowing. There doesn't seem to be anything "tricky" about that. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4