[issue22147] PosixPath() constructor should not accept strings with embedded NUL bytes
New submission from Isaac Schwabacher: This is listed as a python3.4 issue even though I only tried this on the python2.7 backport because I don't have a python3 handy, but I was not able to find an indication, either here or elsewhere, that this had been addressed. Please forgive me if it has. The `pathlib.PosixPath()` constructor currently accepts strings containing NUL bytes, converting them into paths containing NUL bytes. POSIX specifies that a pathname may not contain embedded NULs. It appears that `PosixPath.stat()` is checking for embedded NUL, but `PosixPath.open()` is not! For safety, constructing a `PosixPath` with embedded NULs should be forbidden. `pathlib.WindowsPath()` should probably receive the same treatment. Observed behavior: ```python >>> from pathlib import Path >>> Path("\0I'm not malicious, I'm mischievous!") PosixPath("\x00I'm not malicious, I'm mischievous!") >>> _.open() Traceback (most recent call last): File "", line 1, in File ".../site-packages/pathlib.py", line 1077, in open return io.open(str(self), mode, buffering, encoding, errors, newline) IOError: [Errno 2] No such file or directory: '' >>> Path('/') / _ PosixPath("/\x00I'm not malicious, I'm mischievous!") >>> _.open() Traceback (most recent call last): File "", line 1, in File ".../site-packages/pathlib.py", line 1077, in open return io.open(str(self), mode, buffering, encoding, errors, newline) IOError: [Errno 21] Is a directory: "/\x00I'm not malicious, I'm mischievous!" >>> _.stat() Traceback (most recent call last): File "", line 1, in File ".../site-packages/pathlib.py", line 1051, in stat return self._accessor.stat(self) File ".../site-packages/pathlib.py", line 346, in wrapped return strfunc(str(pathobj), *args) TypeError: must be encoded string without NULL bytes, not str >>> p1 = Path('/etc/passwd\0/hello.txt').open() >>> p2 = Path('/etc/passwd').open() >>> os.path.sameopenfile(p1.fileno(), p2.fileno()) True # DANGER WILL ROBINSON! ``` Expected behavior: ```python >>> Path("/\0I'm not malicious, I'm mischievous!") ... ValueError: Illegal byte '\x00' in path ``` -- messages: 224880 nosy: ischwabacher priority: normal severity: normal status: open title: PosixPath() constructor should not accept strings with embedded NUL bytes type: security versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22147] PosixPath() constructor should not accept strings with embedded NUL bytes
Isaac Schwabacher added the comment: Further digging reveals that the issue with `open()` was fixed in #13848 (the bug was in the `io` module). I still believe that this should fail in the `pathlib.Path` constructor, but this is less of a security issue. -- type: security -> behavior ___ Python tracker <http://bugs.python.org/issue22147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21039] pathlib strips trailing slash
Isaac Schwabacher added the comment: This may be only syntactic sugar, but it is POSIX-specified syntactic sugar: according to http://pubs.opengroup.org/onlinepubs/9699919799/. trailing slashes in pathnames are semantically meaningful in pathname resolution. Tilde escapes are not mentioned. 4.12 Pathname Resolution [...] A pathname that contains at least one non- character and that ends with one or more trailing characters shall not be resolved successfully unless the last pathname component before the trailing characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved. Interfaces using pathname resolution may specify additional constraints[1] when a pathname that does not name an existing directory contains at least one non- character and contains one or more trailing characters. If a symbolic link is encountered during pathname resolution, the behavior shall depend on whether the pathname component is at the end of the pathname and on the function being performed. If all of the following are true, then pathname resolution is complete: 1. This is the last pathname component of the pathname. 2. The pathname has no trailing . 3. The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic link itself. In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. [...] -- nosy: +ischwabacher ___ Python tracker <http://bugs.python.org/issue21039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25831] dbm.gnu leaks file descriptors on .reorganize()
New submission from Isaac Schwabacher: I found because test_dbm_gnu fails on NFS; my initial thought was that the test was failing to close a file somewhere (similarly to #20876), but a little digging suggested that the problem is in dbm.gnu itself: $ ./python Python 3.5.1 (default, Dec 9 2015, 11:55:23) [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import dbm.gnu >>> import subprocess >>> db = dbm.gnu.open('foo', 'c') >>> db.reorganize() >>> db.close() >>> subprocess.check_call(['lsof', 'foo']) COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME python 2302377 schwabacher mem-W REG 0,5298304 25833923756 foo 0 A quick look at _gdbmmodule.c makes clear that the problem is upstream, but their bug tracker has 9 total entries... The best bet might just be to skip the test on NFS. -- components: Library (Lib) messages: 256159 nosy: ischwabacher priority: normal severity: normal status: open title: dbm.gnu leaks file descriptors on .reorganize() type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25831] dbm.gnu leaks file descriptors on .reorganize()
Isaac Schwabacher added the comment: Further searching reveals this as a dupe of #13947. Closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue25831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20876] python -m test test_pathlib fails
Isaac Schwabacher added the comment: This behavior is caused by the way NFS clients implement unlinking open files: instead of unlinking an open file, the filesystem renames it to .nfs and unlinks it on close. (The search term you want is "silly rename".) The reason this problem appears is that `test.support.fs_is_case_insensitive()` unlinks but fails to close the temporary file that it creates. Of course, any attempt to unlink the .nfs file (for instance, by `shutil.rmtree`) just succeeds in renaming it to .nfs, so there is no way to delete the parent directory until the file is closed. The attached patch modifies the offending function to use the `tempfile.NamedTemporaryFile` context manager, which closes the file on leaving the block. -- keywords: +patch nosy: +ischwabacher Added file: http://bugs.python.org/file38289/test_support.patch ___ Python tracker <http://bugs.python.org/issue20876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21483] Skip os.utime() test on NFS?
Isaac Schwabacher added the comment: Patch to do precisely this. Wish I'd spent more time searching for this thread and less time debugging; it would have saved me a lot of trouble. -- keywords: +patch nosy: +ischwabacher Added file: http://bugs.python.org/file38291/test_import.patch ___ Python tracker <http://bugs.python.org/issue21483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19884] Importing readline produces erroneous output
Isaac Schwabacher added the comment: >From the OP: > This was reported at [1] and originally at [2]. The readline maintainer > suggests [3] using: > > rl_variable_bind ("enable-meta-key", "off"); > > which was introduced in readline 6.1. Do you think it'd be safe to add the > above line? >From 3.4.3 final: > @unittest.skipIf(readline._READLINE_VERSION < 0x0600 > and "libedit" not in readline.__doc__, > "not supported in this library version") The test currently fails on readline version 6.0. The version to test on needs a bump to 0x0610. -- nosy: +ischwabacher ___ Python tracker <http://bugs.python.org/issue19884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19884] Importing readline produces erroneous output
Isaac Schwabacher added the comment: Whoops, that's 0x0601. Though Maxime gives evidence that the version should in fact be 0x0603. (Note that while OS X ships with libedit over libreadline, anyone who wants to can install the real thing instead of that pale imitation; the test would have been skipped if Maxime were using libedit.) -- ___ Python tracker <http://bugs.python.org/issue19884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21483] Skip os.utime() test on NFS?
Isaac Schwabacher added the comment: ...and fixed a spot where git diff + copy/paste truncated a long line. /sheepish -- Added file: http://bugs.python.org/file38346/test_import.patch ___ Python tracker <http://bugs.python.org/issue21483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20876] python -m test test_pathlib fails
Isaac Schwabacher added the comment: Fixed a truncated line in the patch. -- Added file: http://bugs.python.org/file38347/test_support.patch ___ Python tracker <http://bugs.python.org/issue20876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com