Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 578: Python Runtime Audit Hooks
Nick Coghlanncoghlan at gmail.com
Sat Mar 30 10:47:32 EDT 2019
On Sat, 30 Mar 2019 at 06:14, Steve Dower <steve.dower at python.org> wrote:> On 29Mar2019 1218, Christian Heimes wrote:> > On 28/03/2019 23.35, Steve Dower wrote:> >> There is no Python API provided for changing the open hook. To modify> >> import behavior from Python code, use the existing functionality> >> provided by ``importlib``.> >> > I think that the import hook needs to be extended. It only works for> > simple Python files or pyc files. There are at least two other important> > scenarios: zipimport and shared libraries.> >> > For example how does the importhook work in regarding of alternative> > importers like zipimport? What does the import hook 'see' for an import> > from a zipfile?>> Yes, good point. I think opening the zip file with open_for_import() is> the right place to do it, as this operation relates to opening the file> on disk rather than files within it.I like this PEP in principle, but the specific "open_for_import" namebothers me a lot, as it implies that "importing" is the only situationwhere a file will be opened for code execution. Accordingly, I thinkproceeding with that name will increase the risk of unintentionalaudit bypasses, as folks (both within the core development team andoutside it) use the regular open function for data that they then passto exec(), or for some other purpose that nevertheless allowsarbitrary code execution (e.g. the shelve module loading pickle filesfrom disk).If this part of the API were lower down the stack (e.g."_io.open_for_code_execution") then I think it would make more sense -APIs like tokenize.open(), runpy.run_path(), PyRun_SimpleFile(),shelve, etc, could use that, without having to introduce a dependencyon importlib to get access to the functionality.Cheers,Nick.-- Nick Coghlan |ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭