[issue42458] Pathlib resolve() on Mac Catalina prepends secret path
New submission from John Engelke :
On Mac OS X Catalina+, Pathlib's resolve() method prepends the System Integrity
Protection (SIP) path to the front of the resolved Path, whether you like it or
not.
>>> from pathlib import Path
>>> host_path_str = "/home/somewhere/there/../nowhere"
>>> host_path = Path(host_path_str)
>>> host_path
PosixPath('/home/somewhere/there/../nowhere')
>>> host_path.resolve()
PosixPath('/System/Volumes/Data/home/somewhere/nowhere')
>>> import platform
>>> platform.platform()
'Darwin-19.6.0-x86_64-i386-64bit'
>>> import sys
>>> print (sys.version)
3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 16:52:21)
[Clang 6.0 (clang-600.0.57)]
>>>
In my particular case, I'm just using this feature to resolve paths for an FTP
host, so the path is contrived and doesn't actually exist locally. As one may
guess, this breaks my FTP transfers by foisting a path on me that isn't on the
server.
I know there are other tix for Pathlib's erratic behavior across platforms
which don't talk about this specific issue. I don't think it a behavior across
platforms thing, anyway. Pathlib obviously isn't behaving nicely with SIP and
Apple's Firmlink wormhole like directory traversal stuffs. Oy vey!
--
components: macOS
messages: 381792
nosy: john.engelke, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Pathlib resolve() on Mac Catalina prepends secret path
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue42458>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42458] Pathlib resolve() on Mac Catalina prepends secret path
John Engelke added the comment: Thanks @ronaldoussoren. This bug report is flawed for a couple reasons, notwithstanding some assumptions I made incorrectly. (SIP actually makes "/home" a symlink so that resolved correctly.) So I am retracting it as-is because I can't edit the original report. The documentation for the behavior of resolve() is talking about using resolve() in the PurePath section. And, resolve() is removing "/../" when the path doesn't really exist locally. I'll open clearer tickets about those when I have a chance. -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue42458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42458] Pathlib resolve() on Mac Catalina prepends secret path
Change by John Engelke : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42458] Pathlib resolve() on Mac prepends path
Change by John Engelke : -- title: Pathlib resolve() on Mac Catalina prepends secret path -> Pathlib resolve() on Mac prepends path ___ Python tracker <https://bugs.python.org/issue42458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42464] Pathlib resolve() resolves non-existent ".." components with strict=False
New submission from John Engelke :
The below snippet results in the symlink "/home" resolving as expected.
However, documentation at
https://docs.python.org/3.7/library/pathlib.html#pathlib.Path.resolve suggests,
"If strict is False, the path is resolved as far as possible and any remainder
is appended without checking whether it exists."
>>> from pathlib import Path
>>> host_path_str = "/home/somewhere/there/../nowhere"
>>> host_path = Path(host_path_str)
>>> host_path
PosixPath('/home/somewhere/there/../nowhere')
>>> host_path.resolve()
PosixPath('/System/Volumes/Data/home/somewhere/nowhere')
Expected results (based on the wording above):
>>> host_path.resolve()
PosixPath('/System/Volumes/Data/home/somewhere/there/../nowhere')
Right now the ".." pieces are universally removed. I'm not exactly sure exactly
how symlinks resolve, but this might create unexpected results.
No part of the path component "somewhere/there/../nowhere" exists. When
strict=True this would yield an error. So when strict=False, and it doesn't
resolve, documentation implies that would be re-added to the resolved section.
--
components: Library (Lib)
messages: 381844
nosy: john.engelke
priority: normal
severity: normal
status: open
title: Pathlib resolve() resolves non-existent ".." components with strict=False
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42464>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42465] Reference to subclass method resolve() in PurePath docs
New submission from John Engelke : The text: 'If you want to walk an arbitrary filesystem path upwards, it is recommended to first call Path.resolve() so as to resolve symlinks and eliminate “..” components.' should be moved or changed to 'If you want to walk a concrete path upwards, it is recommended to first call Path.resolve() so as to resolve symlinks and eliminate “..” components.' Rationale: Wording is confusing as the resolve() method doesn't exist for PurePath, PurePosixPath nor PureWindowsPath. It's unclear that the method applies only to concrete implementations of the Path subclass. This should be resolved by either altering the above text or (preferably) moving it to the concrete Path section. NOTE: PurePath (PurePosixPath, PureWindowsPath) operations are described in docs as "purely computational" components that "don’t actually access a filesystem." https://docs.python.org/3.7/library/pathlib.html#pure-paths -- assignee: docs@python components: Documentation messages: 381848 nosy: docs@python, john.engelke priority: normal severity: normal status: open title: Reference to subclass method resolve() in PurePath docs versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
