help-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-tar] colon in archive name and force local


From: Martin Bukatovic
Subject: [Help-tar] colon in archive name and force local
Date: Mon, 5 Mar 2018 23:27:34 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

Hello tar-help list,

I stumbled upon a feature of GNU tar I wasn't aware about and I have to
admit that I'm not sure I understand both the reasoning behind this
feature and choice of the default behavior, and I'm hope that I can get
some missing context from you.

Excerpt from current GNU tar manual follows:

>  If the archive file name includes a colon (`:'), then it is assumed
>  to be a file on another machine. If the archive file is
>  address@hidden:file', then file is used on the host host. The remote host
>  is accessed using the rsh program, with a username of user. If the
>  username is omitted (along with the `@' sign), then your user name
>  will be used. (This is the normal rsh behavior.) It is necessary for
>  the remote machine, in addition to permitting your rsh access, to
>  have the `rmt' program installed (this command is included in the GNU
>  tar distribution and by default is installed under
>  `prefix/libexec/rmt', where prefix means your installation prefix).
>  If you need to use a file whose name includes a colon, then the
>  remote tape drive behavior can be inhibited by using the
>  `--force-local' option.

And looking into NEWS file, this feature is there since 1992:

> Version 1.11 - Michael Bushnell, 1992-09.
> Version 1.10.16 - 1992-07.
> Version 1.10.15 - 1992-06.
> Version 1.10.14 - 1992-05.
> Version 1.10.13 - 1992-01.
> 
> * Remote archive names no longer have to be in /dev: any file with a
> ':' is interpreted as remote.  If new option --force-local is given,
> then even archive files with a ':' are considered local.

The first detail where I would like to verify my understanding is the
reason why this feature was introduced in the first place. I'm assuming
that the expected use case is to access remote tape device, which I can
do even without the feature via pipe something like:

  $ tar cf - something | ssh remotehost "cat > /dev/sr0"

But since the command is much shorter using the feature:

  $ tar cf remotehost:/dev/sr0 something

This thing looks like shell syntactic sugar, helping simplify a common
use case, which is possible to achieve without it. Is that correct?

Then I don't understand the choice of the default behavior. If I were
implementing this nowadays, I would define an option (something like
--remote-file) to enable it so that having a colon in a filename would
not do anything special, unless the new option is specified. Why was the
opposite (the feature is enabled by default, unless --force-local
option is specified) chosen there? 

One reason I'm asking is that this particular choice, which GNU tar
decided to use, introduces a conflict with local and remote filenames. I
could name a tarball file in a way so that when GNU tar will try to
access some remote file instead and fail.

And if I store some archive file on the remote machine on expected
location, I could even end up with tar extracting completely different
remote file instead of a local one :) But I have to admit, that this is
very special edge case. To trick someone with a tarball with such
special name would require "a victim" to not notice that there is a
hostname or ip address in a tarball name, to guess the login of the
user account under which the tar is used, to have victim's ssh public
key, that the victim either doesn't use password for the ssh key or has
the password currently cached in ssh agent and last but not least, that
the victim already has fingerprint of my remove server in it's known
hosts or has disabled fingerprint checking. And I haven't even mentioned
network speed limitations.

This hardly qualify even as a practical joke to trick a friend with :)

That said, I'm still amazed that, under these unlikely conditions I
listed above, it actually works:

  $ cd ~/tmp
  $ touch good-file bad-file
  $ tar caf bad.tar.gz bad-file
  $ tar --force-local -caf localhost:bad.tar.gz good-file
  $ cp bad.tar.gz ~
  $ tar tf localhost:bad.tar.gz
  bad-file
  $ tar --force-local -tf localhost:bad.tar.gz
  good-file


-- 
Martin Bukatovic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]