Solved

After interesting/insightful inputs from different users, here are the takeaways:

  • It doesn’t have some critical or dangerous impact or implications when extracted
  • It contains the tared parent folder (see below for some neat tricks)
  • It only overwrites the owner/permission if ./ itself is included in the tar file as a directory.
  • Tarbombs are specially crafted tar archives with absolute paths / (by default (GNU) tar strips absolute paths and will throw a warning except if used with a special option –absolute-names or -P)
  • Interesting read: Path-traversal vulnerability (../)

Some neat trick I learned from the post

Temporarily created subshell with its own environment:

Let’s say you’re in the home directory that’s called /home/joe. You could go something like:

> (cd bin && pwd) && pwd
/home/joe/bin
/home/joe

source

Exclude parent folder and ./ ./file from tar

There are probably a lot of different ways to achieve that expected goal:

(cd mydir/ && tar -czvf mydir.tgz *)

find mydir/ -printf "%P\n" | tar -czf mytar.tgz --no-recursion -C mydir/ -T - source


The absolute path could overwrite my directory structure (tarbomb) source Will overwrite permission/owner to the current directory if extracted. source

I’m sorry if my question wasn’t clear enough, I’m really doing my best to be as comprehensible as possible :/


Hi everyone !

I’m playing a bit around with tar to understand how it works under the hood. While poking around and searching through the web I couldn’t find an actual answer, on what are the implication of ./ and ./file structure in the tar archive.

Output 1

sudo find ./testar -maxdepth 1 -type d,f -printf "%P\n" | sudo tar -czvf ./xtractar/tar1/testbackup1.tgz -C ./testar -T -
#output
> tar tf tar1/testbackup1.tgz 

text.tz
test
my
file.txt
.testzero
test01/
test01/never.xml
test01/file.exe
test01/file.tar
test01/files
test01/.testfiles
My test folder.txt

Output 2

sudo find ./testar -maxdepth 1 -type d,f  | sudo tar -czvf ./xtractar/tar2/testbackup2.tgz -C ./testar -T -
#output
>tar tf tar2/testbackup2.tgz

./testar/
./testar/text.tz
./testar/test
./testar/my
./testar/file.txt
./testar/.testzero
./testar/test01/
./testar/test01/never.xml
./testar/test01/file.exe
./testar/test01/file.tar
./testar/test01/files
./testar/test01/.testfiles
./testar/My test folder.txt
./testar/text.tz
./testar/test
./testar/my
./testar/file.txt
./testar/.testzero
./testar/test01/
./testar/test01/never.xml
./testar/test01/file.exe
./testar/test01/file.tar
./testar/test01/files
./testar/test01/.testfiles
./testar/My test folder.txt

The outputs are clearly different and if I extract them both the only difference I see is that the second outputs the parent folder. But reading here and here this is not a good solution? But nobody actually says why?

Has anyone a good explanation why the second way is bad practice? Or not recommended?

Thank you :)

  • kevincox@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    8 months ago

    A “tarbomb” usually refers to an archive that has multiple (often a large number) of top-level items. Traditionally a tar archive contains a single folder, which may contain more things inside of this. This can be annoying because if you do tar -xf tarbomb.tar in your home directory (or downloads folder) you now have a bit of a mess that you need to clean up.

    It is a bit of a historical artifact, most archive managers will create a folder for the contents if there are multiple top-level items, and you really shouldn’t be extracting archives in directories with other files anyways as it could be a security issue (for example if there is a .profile or .ssh/authorized_keys file in that archive). Of course tar won’t protect you by default unless you pass --one-top-level.

    I think what you are concerned about is a path-traversal vulnerability where tar will write files outside of the current directory. Any modern tar should not allow this, no matter what the archive contains.

    • N0x0n@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      Thank you for the clarification ! That’s way most post are from 2007 and couldn’t find any recent documentation !

      Will take a look at path-traversal vulnerability thanks for the info !

  • SpaceCadet@feddit.nl
    link
    fedilink
    English
    arrow-up
    3
    ·
    8 months ago

    Has anyone a good explanation why the second way is bad practice? Or not recommended?

    They’re functionally the same. It’s like the difference between mkdir somedir and mkdir ./somedir. The leading ./ is not necessary, so I guess you could consider it less clean, but I wouldn’t lose any sleep over it.

    • N0x0n@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      Haha, thank you xD I think I wouldn’t lose my sleep over it, except if I tarbomb my server !! My question was probably baddly written, but this kind of structure could actually be dangerous !

      • SpaceCadet@feddit.nl
        link
        fedilink
        English
        arrow-up
        2
        ·
        8 months ago

        this kind of structure could actually be dangerous

        citation needed

        I mean, tarbombs exist, but not because of the leading ./ as far as I know and they’re usually specifically crafted tar files to create harm, not something you accidentally create yourself while tarring stuff.

        • N0x0n@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          You’re right :) In my current example it’s probably “harmless” if extracted properly in a separated folder. Maybe I do not understand how it works (please educate me :)) but if my tar contains the following folder./home/user/ and I extract it in my current home folder (which would be kinda stupid but It happens) this will overwrite the home folder (which is the principle of a tarbomb? mess up and overwrite directories?).

          A related problem is the use of absolute paths or parent directory references when creating tar files. Files extracted from such archives will often be created in unusual locations outside the working directory and, like a tarbomb, have the potential to overwrite existing files. However, modern versions of FreeBSD and GNU tar do not create or extract absolute paths and parent-directory references by default, unless it is explicitly allowed with the flag -P or the option --absolute-names. source

          There’s still another odd behavior with ./ ! When extracted it will overwrite the permission/owner to the current directory source

          • SpaceCadet@feddit.nl
            link
            fedilink
            English
            arrow-up
            1
            ·
            8 months ago

            There’s still another odd behavior with ./ ! When extracted it will overwrite the permission/owner to the current directory source

            Only if ./ itself is included in the tar file as a directory.

          • SpaceCadet@feddit.nl
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            8 months ago

            If my tar contains the following folder ./home/user/ and I extract it in my current home folder (which would be kinda stupid but It happens) this will overwrite the home folder

            No it will not. It will extract your files to /home/user/home/user, so a nested home directory inside your home directory (yo dawg).

            The man page section you quote is about absolute paths. That is, paths that start with a / without a leading dot. They indeed can be dangerous, but by default (GNU) tar strips absolute paths and will throw a warning like:

            # tar -cf test.tar /etc/hosts
                               ^leading slash
            tar: Removing leading `/' from member names
            
            # tar -tvf test.tar
            -rw-r--r-- root/root       184 2022-12-08 20:27 etc/hosts
                                                           ^no leading slash
            
            
            • N0x0n@lemmy.mlOP
              link
              fedilink
              arrow-up
              1
              ·
              8 months ago

              Thank you very much for the clarification ! That’s exactly the kind of input I was looking for ! I tried it out and your absolutely right ! I will edit my post.

            • N0x0n@lemmy.mlOP
              link
              fedilink
              arrow-up
              1
              ·
              8 months ago

              Thanks after a long sleep I edited my post to avoid misinformation and errors due of my lacked knowledge ! Thanks for your time and clarifications on that specific point !

  • FigMcLargeHuge@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    8 months ago

    You probably want to step back and look at the output of your find command. That is where your difference is coming from. The printf is giving you just the files, while the non-printf line is giving you the folder name first. When I am usually doing something like this, I will send the output of the find command to a file, and then use that file as the input for the tar command. That gives me a chance to take a look at the files that are going to be tarred up. In output 2, you are getting your base folder included in the tar file, which as you have noticed, you may or may not want. You are also getting different data as you have -maxdepth=1 on your find command.

    Edit: So I may not have explained what you were asking about. The implication here is that you will have to be careful where you untar this file based on whether or not you want your “testar” folder laid down when it’s untarred. I noticed that you are also getting duplicates in your output 2 tar file, because you are feeding it the folder, and then the folder contents. So it tars up the folder and then you come after that and feed it the files contained in the folders.

    • N0x0n@lemmy.mlOP
      link
      fedilink
      arrow-up
      3
      ·
      8 months ago

      Thank you ! Your edit is related to what’s called a tarbomb. I also found out that it will overwrite the owner and permission to the current directory… Very odd behavior ! source

      I noticed that you are also getting duplicates in your output 2 tar file, because you are feeding it the folder, and then the folder contents. 
      

      Haha, that was only an example xD to get context. My english is not that good, so I have to somehow show what I mean.

      • FigMcLargeHuge@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 months ago

        No problem. Again, I wouldn’t feed tar output from a find command when you are getting all files and folders (-type d,f). Just let tar go grab everything on it’s own. If you need to feed it a list of files, use find to export the list, and then check it before you let tar run on that output. Just my two cents.

        • N0x0n@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          8 months ago

          Thanks ! I changed that specific point my command looks way cleaner now ! But I still use the find command to extract the names with -printf "%P\n" to tar only the files without the parent folder and ./ ./files. I prefere it that way, it looks cleaner. But -type d,f is useless !

          use find to export the list, and then check it before you let tar run on that output

          This seems a more secure way of doing things. Do you have any personal experience with piped tar commands that back slashed and put your system at risk?

          Edit: I just found an easier way… (cd testar/ && tar -czvf ../mydir.tgz {*,.*}) Which includes hidden files without parent folder and ./ !

          • FigMcLargeHuge@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            2
            ·
            8 months ago

            Do you have any personal experience with piped tar commands that back slashed and put your system at risk?

            No, I do not. I never even thought of piping output to a tar command, and I have been using tar so long that I have run the command on an actual tape archive. I use the -T option quite a bit, but I always test the input file before ever running the command. If I don’t generate the list of files and use -T, then I just let tar do the file selection.

  • tunetardis@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    8 months ago

    I think that since you’re piping in the file list from find, the -C ./testar in the tar command is basically irrelevant? You probably need to cd ./testar before the find. Maybe you could do that in a subshell so that the cd doesn’t affect your tar archive path? So something like:

    (sudo cd ./testar && sudo find ./ -maxdepth 1 -type d,f)  | sudo tar -czvf ./xtractar/tar2/testbackup2.tgz -T -
    
    • tunetardis@lemmy.ca
      link
      fedilink
      arrow-up
      3
      ·
      8 months ago

      Ok, I actually tried something like this at a terminal. You do still need the -C ./testar if you use the subshell since tar won’t know where to look otherwise.

      (sudo cd ./testar && sudo find . -maxdepth 1 -type d,f)  | sudo tar -czvf ./xtractar/tar2/testbackup2.tgz -C ./testar -T -
      

      This will still give you a listing with ./text.tz and so on because find prints ./whatever when you search .. I think this is harmless? But I suppose you could remove them if it bothers you.

      (sudo cd ./testar && sudo find . -maxdepth 1 -type d,f)  | cut -c3- | sudo tar -czvf ./xtractar/tar2/testbackup2.tgz -C ./testar -T -
      
      • N0x0n@lemmy.mlOP
        link
        fedilink
        arrow-up
        2
        ·
        8 months ago

        Thank you for testing it out and give some nice insights on how to improve the command. Just curious what’s about the parenthesis (sudo cd ./testar && sudo find . -maxdepth 1 -type d,f)? I have never seen a command structured like that !

        Regarding my question, someone lead me to the right direction. This could overwrite my actual folder structure (tarbomb) depending on where it’s extracted and the absolute path in the tar. It will also extract the permission and ownership to the current directory… source

        • tunetardis@lemmy.ca
          link
          fedilink
          arrow-up
          2
          ·
          8 months ago

          The commands within the parentheses run in a temporarily created subshell with its own environment. So you can change the working directory within it and it won’t effect your main shell’s working directory.

          Let’s say you’re in the home directory that’s called /home/joe. You could go something like:

          > (cd bin && pwd) && pwd
          /home/joe/bin
          /home/joe
          

          If find had something equivalent to tar -C, you wouldn’t need to do this, but I don’t think it does?

          • N0x0n@lemmy.mlOP
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            8 months ago

            Thank youuu !! I learned something really interesting !!! :)

            (sudo cd ./testar && sudo find . -maxdepth 1 -type d,f) | cut -c3- | sudo tar -czvf ./xtractar/tar2/testbackup2.tgz -C ./testar -T -

            So, you’re trying to sudo cd ? :P I tried a hacky way I found on superuser.com sudo sh -c 'cd dirname' doesn’t work -_- !

            Thank you very much :))) The cut -c3- is a nice alternative !!

            • tunetardis@lemmy.ca
              link
              fedilink
              arrow-up
              3
              ·
              8 months ago

              Oh yeah, that’s another way to make a subshell. But don’t forget to stick the find in there also:

              sudo sh -c 'cd ./testar && find . -maxdepth 1 -type d,f' | ...
              
  • will_a113@lemmy.ml
    link
    fedilink
    English
    arrow-up
    2
    ·
    8 months ago

    In UNIX-y systems ./ is your current local directory, so if I was in /usr/home/will and I extracted your file I would expect any file that was like ./foo.txt to be extracted to /usr/home/will/foo.txt, and if there were files like ./testar/bar.txt, they would be extracted to a new directory /usr/home/will/testar/bar.txt – or is that not what you’re talking about?

  • bionicjoey@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    8 months ago

    I’m not certain, but I’m guessing it may be related to absolute versus relative file paths.

  • hperrin@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    8 months ago

    Having a ./ in front of your file names in a tar won’t hurt anything, it’s just unnecessary.

    • N0x0n@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      Hey :) Thanks for your input but after some insight from other users I actually found out it could overwrite my folder structure (tarbomb) and also overwrite the permission/owner to the current directory (see my edited post for source). My example is probably really bad because it doesn’t contain any absolute path, but the permission/owner change still holds in the current directory.

      Sorry if my question was badly written.

      • hperrin@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        8 months ago

        I believe you’d only overwrite ownership/permission of ./ if that was included in your tar.

        Also, ./ is a relative path. Absolute paths start with /.

        The source you linked about tarbombs is talking about a tar that doesn’t use a subdirectory, not one that uses ./ prefixes.

  • eveninghere@beehaw.org
    link
    fedilink
    arrow-up
    1
    ·
    8 months ago

    I don’t want:

    my_directory
       --- my_file
       --- my_file
       --- my_file
    

    I want:

    my_file
    my_file
    my_file
    

    Quoted from the question.

    • N0x0n@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      Yeah but that doesn’t answer my question: What’s the implication of ./ in the tar file? I mean when I extract them, both seem similar but most people say it’s bad practice or not recommended but why?

      I know and do understand how to achieve both with and without the root folder.

        • N0x0n@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          8 months ago

          Thank you, I think this is a good lead, but couldn’t find a lot of information about it. But the general gist is that it could overwrite my folder structure and mess up the filesystem (source). All sources I found are very old, does that mean that there’s some kind of protection today?

          I also found out that it will extract the permission and owner to the current directory :/ so this a very odd behavior… (source).

          Thank you for your answer !

          • eveninghere@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            8 months ago

            I doubt there’s a perfect protection. Maybe some tar implementations asks confirmation before tar-bombing, but it then wouldn’t work for non-interactive sessions, etc.

            tar overwrites permissions because tar was meant for archiving iirc. Although, there might be a command line option to change its behavior.

            Perhaps, the zip command is better for your purpose. It doesn’t allow zip-bombs and perhaps doesn’t overwrite permission.