importlib.resources opens Windows device names

Bug report

Bug description:

The underlying issue here came up in #88992, but it seems like regardless of how this is fixed in zoneinfo, there may also be changes that should happen in importlib.resources as well, so I'm splitting this off into a new issue.

Apparently on Windows, there are certain special reserved device names like CON and NUL which you can open from within any directory, which means stuff like this will always succeed:

import importlib.resources

PACKAGE = "tzdata"  # This can be any package

importlib.resources.files(PACKAGE).open_binary("CON")

It seems that Windows is improving this, so that particular example might not work on modern Windows systems, but "NUL" still does. To the extent that CON still works, however, it's a particularly dangerous example because it starts reading from STDIN, which is not really what people are expecting here.

In general, importlib.resources is intended to be able to load resources from a package, but these special devices are not part of the package, and importlib.resources is only opening them as a quirk of the implementation. We should now allow these implementation details to leak into the interface.

From what I can tell these are kind of hard to detect, but I believe they don't show up when you actually list the contents of a directory, so in the worst case scenario we can do something like this:

if name not in os.listdir(parent):
    raise FileNotFoundError(...)

That would be fairly slow in the common case, though, so we can probably use some heuristics to narrow down whether or not we might be in the situation where we are about to open a Windows device, like so:

if OS_IS_WINDOWS and name in FROZEN_SET_OF_INTERFACE_NAMES and name not in os.listdir(parent):
    raise FileNotFoundError(...)

(This can possibly be simplified by having FROZEN_SET_OF_INTERFACE_NAMES be set to frozenset() at compile time in non-windows operating systems)

I'm assuming that we have a comprehensive list of all the reserved names that would have this property on any OS version, and FROZEN_SET_OF_INTERFACE_NAMES can be basically that list, or it can be a list determined at compile time based on your OS version. I'm also assuming that since it seems like this special devices thing is mostly going away, that list will never get any bigger, just smaller.

A related issue here is that importlib.resources also tends to return a bunch of stuff that is not actually a resource in the package, lke __init__.py and __pycache__. These do show up in iterdir and resources.is_resource(PACKAGE, "__init__.py") will return True, so these are a trickier case. If we end up with a solution that excludes these as well I'd be happy about it, but I think the more pressing issue is the device name thing, which is highly surprising and kind of obscure, platform-specific knowledge, so a lot of people won't even know to check for it and may not even have a machine on which it would cause problems.

@python/importlib-team @zooba @encukou

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-136419
• gh-137038
• gh-137039

Revise os PRs vinculados gh-136419, gh-137038 e gh-137039 e, em seguida, inspecione a implementação de importlib.resources e seu comportamento de abertura de recursos no Windows. Reproduza o exemplo de NUL ou CON no Windows e identifique os testes existentes que cobrem a busca de recursos. A tarefa estará concluída quando nomes de dispositivos reservados não forem abertos como recursos de pacote, enquanto os recursos de pacote comuns continuarem funcionando.