On 21/11/2019 18.27, Jason Killen wrote: > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > switch to using io.open_code when appropriate. In the process of making > those PRs I spent a bit of time reading the two related PEPs. In > PEP-551 there's a suggestion that people use a restricted entry point in > production environments. I googled around a bit and couldn't find any > evidence that there was an existing implementation, at least not made > public, that people were using in a general sense. So I created a > branch from my fork and over the last few days have implemented part of > what's suggested in PEP-551. Specifically my changes remove most of the > command line options, ignore envvars (except for a possible logging > filename for the audit hooks), and registers an audit hook that logs > everything to the defined envvar when provided or stderr if not.
As Steve already pointed out, https://github.com/zooba/spython contains examples examples for Windows and Linux. The linux_xattr is a PoC that I developed for our joined talk at EuroPython 2019. > Now the questions: > 1) Does anybody care? Is anyone currently doing this or planning on > doing this? > 2) Do we want to provide an "official" version of a restricted entry > point that could be used as-is or easily modified per specific needs? > Seems kinda silly to make everyone roll their own version but I'm happy > to yield to the will of the people. > 3) What's the chance we wanna merge something like this into the > official master branch? I accomplished what I wanted to do using a few > #ifdef's and some funky makefile magic. I think it would merge easily. > Maintaining a fork sounds like a lot of work to me. Yes, we still care. Steve has been more active on the Windows side than me on the Linux side. Please keep in mind that the feature is new to Python 3.8 and 3.8.0 just came out a little more than a month ago. It's going to take a while until major vendors will make use of the feature. PEP 578 features require distribution and vendor-specific adjustments. For example it makes sense to disable byte code compilation and usage on Windows. On the other hand RPM based platforms like RHEL always want to use precompiled byte code because PYC files are shipped with RPM packages. > And here's the code: > I'm very open to suggestions. I basically have no idea what I'm doing. > I haven't touched C in about 7 years so don't expect the Mona Lisa. > https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point Thanks for your work! Prototypes like this are useful to figure out how Python's configuration should be improved. Eventually it should not be necessary to modify any code in CPython to create an spython interpreter. I like to reach a state in which it is possible to configure all these flags by providing a custom configuration. Victor's new config system in 3.8 can accomplish almost everything. It is currently not possible to modify argument parsing, though. One comment about your implementation: You are logging to a file. It's not very useful to log to a target in the same security context except for debugging. If an attacker is able to compromise the interpreter, then the attacker most likely gains enough privileges to wipe the file. That's why Steve uses the Windows event log in his examples and I'm going for syslog and journald. These logging system run as a different user and log files are protected by additional means, e.g. SELinux. I have been working on structures journald logging recently. Christian _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HCSME57BS2AEAATLFMPLCKMWUYZX4SCM/ Code of Conduct: http://python.org/psf/codeofconduct/
