Bug report

Bug description:

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

Apparently on Windows, there are certain special reserved device names likeCON andNUL which you can open from withinany directory, which means stuff like this will always succeed:

importimportlib.resourcesPACKAGE="tzdata"# This can be any packageimportlib.resources.files(PACKAGE).open_binary("CON")

It seems thatWindows is improving this, so that particular example might not work on modern Windows systems, but"NUL" still does. To the extent thatCON 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 resourcesfrom a package, but these special devices are not part of the package, andimportlib.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:

ifnamenotinos.listdir(parent):raiseFileNotFoundError(...)

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:

ifOS_IS_WINDOWSandnameinFROZEN_SET_OF_INTERFACE_NAMESandnamenotinos.listdir(parent):raiseFileNotFoundError(...)

(This can possibly be simplified by havingFROZEN_SET_OF_INTERFACE_NAMES be set tofrozenset() 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, andFROZEN_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 thatimportlib.resources also tends to return a bunch of stuff that is not actually a resource in the package, lke__init__.py and__pycache__. Thesedo show up initerdir andresources.is_resource(PACKAGE, "__init__.py") will returnTrue, 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