Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tarfile: Do not write full path in FNAME field #85488

Closed
ArtemSBulgakov mannequin opened this issue Jul 16, 2020 · 6 comments
Closed

tarfile: Do not write full path in FNAME field #85488

ArtemSBulgakov mannequin opened this issue Jul 16, 2020 · 6 comments
Labels
3.8 only security fixes 3.9 only security fixes 3.10 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ArtemSBulgakov
Copy link
Mannequin

ArtemSBulgakov mannequin commented Jul 16, 2020

BPO 41316
Nosy @gustaebel, @ethanfurman, @eamanu, @miss-islington, @ArtemSBulgakov
PRs
  • bpo-41316: Make tarfile follow specs for FNAME #21511
  • [3.9] bpo-41316: Make tarfile follow specs for FNAME (GH-21511) #22140
  • [3.8] bpo-41316: Make tarfile follow specs for FNAME (GH-21511) #22141
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2020-10-21.08:10:09.115>
created_at = <Date 2020-07-16.18:37:23.017>
labels = ['3.8', 'type-bug', 'library', '3.9', '3.10']
title = 'tarfile: Do not write full path in FNAME field'
updated_at = <Date 2020-10-21.08:10:09.114>
user = 'https://github.com/ArtemSBulgakov'

    bugs.python.org fields:

    activity = <Date 2020-10-21.08:10:09.114>
actor = 'methane'
assignee = 'none'
closed = True
closed_date = <Date 2020-10-21.08:10:09.115>
closer = 'methane'
components = ['Library (Lib)']
creation = <Date 2020-07-16.18:37:23.017>
creator = 'ArtemSBulgakov'
dependencies = []
files = []
hgrepos = []
issue_num = 41316
keywords = ['patch']
message_count = 6.0
messages = ['373759', '373790', '373798', '376515', '379194', '379195']
nosy_count = 5.0
nosy_names = ['lars.gustaebel', 'ethan.furman', 'eamanu', 'miss-islington', 'ArtemSBulgakov']
pr_nums = ['21511', '22140', '22141']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue41316'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']
    @ArtemSBulgakov
    Copy link
    Mannequin Author

    ArtemSBulgakov mannequin commented Jul 16, 2020

    tarfile sets FNAME field to the path given by user: Lib/tarfile.py:424

    It writes full path instead of just basename if user specified absolute path. Some archive viewer apps like 7-Zip may process file incorrectly. Also it creates security issue because anyone can know structure of directories on system and know username or other personal information.

    You can reproduce this by running below lines in Python interpreter. Tested on Windows and Linux.

    Python 3.8.2 (default, Apr 27 2020, 15:53:34)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import tarfile
>>> open("somefile.txt", "w").write("sometext")
8
>>> tar = tarfile.open("/home/bulgakovas/file.tar.gz", "w|gz")
>>> tar.add("somefile.txt")
>>> tar.close()
>>> open("file.tar.gz", "rb").read()[:50]
b'\x1f\x8b\x08\x08cE\x10_\x02\xff/home/bulgakovas/file.tar\x00\xed\xd3M\n\xc20\x10\x86\xe1\xac=EO\x90'

    You can see full path to file.tar (/home/bulgakovas/file.tar) as FNAME field. If you will write just tarfile.open("file.tar.gz", "w|gz"), FNAME will be equal to file.tar.

    RFC1952 says about FNAME:
    This is the original name of the file being compressed, with any directory components removed.

    So tarfile must remove directory names from FNAME and write only basename of file.

    @ArtemSBulgakov ArtemSBulgakov mannequin added 3.7 (EOL) end of life 3.10 only security fixes 3.8 only security fixes 3.9 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jul 16, 2020
    @eamanu
    Copy link
    Mannequin

    eamanu mannequin commented Jul 17, 2020

    Hi,

    If I understand correctly, the name that you are using into the tar
    is the basename of the file. I didn't test it yet, but this PR will
    remove the possibility to create a file into the tar using the
    source tree folder?

    Maybe we can think about implement a parameter seems like arcname
    on Zipfile?

    What about that?

    Cheers!

    @ArtemSBulgakov
    Copy link
    Mannequin Author

    ArtemSBulgakov mannequin commented Jul 17, 2020

    Hi. My PR doesn't remove the possibility to add tree into tar file. It only fixes header for GZIP compression. Any data after this header is not affected.

    You can test it by creating two archives with the same data but one with my patch and the second without. All bytes after header are equal.

    @miss-islington
    Copy link
    Contributor

    New changeset 22748a8 by Artem Bulgakov in branch 'master':
    bpo-41316: Make tarfile follow specs for FNAME (GH-21511)
    22748a8

    @miss-islington
    Copy link
    Contributor

    New changeset 7917170 by Miss Skeleton (bot) in branch '3.9':
    bpo-41316: Make tarfile follow specs for FNAME (GH-21511)
    7917170

    @miss-islington
    Copy link
    Contributor

    New changeset e866f33 by Miss Skeleton (bot) in branch '3.8':
    bpo-41316: Make tarfile follow specs for FNAME (GH-21511)
    e866f33

    @methane methane removed the 3.7 (EOL) end of life label Oct 21, 2020
    @methane methane closed this as completed Oct 21, 2020
    @methane methane removed the 3.7 (EOL) end of life label Oct 21, 2020
    @methane methane closed this as completed Oct 21, 2020
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.8 only security fixes 3.9 only security fixes 3.10 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @methane @miss-islington