[issue11879] TarFile.chown: should use TarInfo.uid if user lookup fails
New submission from Michael Gold : In TarFile.chown, if the lookup u = pwd.getpwnam(tarinfo.uname)[2] fails, this line is used: u = pwd.getpwuid(tarinfo.uid)[2] This will fail if the uid isn't in /etc/passwd. I think "u = tarinfo.uid" would make more sense. This fallback could also be used if the pwd module isn't present or tarinfo.uname isn't filled. Here's a code sample: u = tarinfo.uid if tarinfo.uname and pwd: try: u = pwd.getpwnam(tarinfo.uname)[2] except KeyError: pass The same issue applies to group lookup. -- components: Library (Lib) messages: 134074 nosy: mgold-qnx priority: normal severity: normal status: open title: TarFile.chown: should use TarInfo.uid if user lookup fails type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11879> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11899] TarFile.gettarinfo modifies self.inodes
New submission from Michael Gold : When I call tar.gettarinfo (where tar is a TarFile instance), the inode information is inserted into tar.inodes. If I later call tar.gettarinfo on a linked file, the returned TarInfo will have type LNKTYPE. I think it's incorrect to store this information in gettarinfo. It should be done in addfile. A comment in gettarinfo states "Is it a hardlink to an already archived file?". But tar.inodes is modified in gettarinfo, and there's no reason to expect that the file will actually be archived, or will be archived with the same properties. Bad links could result if the returned tarinfo object were modified before calling addfile. I suggest changing the code as follows: - Create a static method (or non-member function) to fill in a given TarInfo object with stat/lstat/fstat results. This would need a boolean "dereference" parameter. (No TarFile instance should be required to create a TarInfo.) - Have tar.gettarinfo call the above function; then fill in tarinfo.tarfile, and modify tarinfo.type to LNKNAME if applicable. Don't modify self.inodes. - In tar.addfile, call fstat, and store the inode info into self.inodes. -- components: Library (Lib) messages: 134220 nosy: lars.gustaebel, mgold-qnx priority: normal severity: normal status: open title: TarFile.gettarinfo modifies self.inodes type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11899] TarFile.gettarinfo modifies self.inodes
Michael Gold added the comment: Actually, TarFile should also have a separate method to take a TarInfo instance and modify its type to LNKTYPE if applicable. gettarinfo can call that. This way the user can use a TarInfo object created before any files are added, and can easily get this linking behaviour if desired. (Note: In my initial message, I had LNKNAME where I meant LNKTYPE.) -- ___ Python tracker <http://bugs.python.org/issue11899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11899] TarFile.gettarinfo modifies self.inodes
Michael Gold added the comment: No, I don't have a working implementation. (I basically reimplemented TarFile.inodes to work around this; I was using TarFile.dereference, so I already had to do the hard-linking manually.) -- nosy: +mgold ___ Python tracker <http://bugs.python.org/issue11899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11879] TarFile.chown: should use TarInfo.uid if user lookup fails
Michael Gold added the comment: The tests passed on Linux (with Python 3.2 under fakeroot): Ran 240 tests in 9.613s OK But I don't see any tests that check the uid/gid of extracted files. -- nosy: +mgold ___ Python tracker <http://bugs.python.org/issue11879> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
