[Bug-tar] segfault getting cwd with --listed-incremental

[J Chapman Flack]

Tested on a Solaris 10 box, tar with --create --listed-incremental
uses (as shown by truss) the old-fashioned method for getting the
cwd: get .'s inum, find it among all of ..'s entries, and repeat.

That method was always known to fail if some ancestral directory
lacked read permission. On ZFS filesystems there is another reason
for the method to fail. Under a ZFS mountpoint is a .zfs
directory that is only there if you are looking for it (does not
show up in a readdir):

$ ls .z*   # nobody here but us chickens
.z*: No such file or directory
$ cd .zfs  # oh, sorry, you mean ME?
$

Because of that, if tar is run beneath the .zfs directory
(for example, in a ZFS snapshot, a reasonable application)
the old algorithm for getting the cwd fails. Instead of
getting EPERM as in the case of an unreadable directory,
it simply reaches the point where . is the .zfs directory
and reads all of .. without finding the match, proceeding
to a segfault.

There could be discussion of what the bug really is. For one
thing, why does --listed-incremental even want to get the cwd?
It seems to put only relative paths in the snar file.  IIRC one
of the goals for GNU tools was to eliminate non-inherent
limitations, and there seem to be enough situations in *n*x
where absolutizing paths leads to problems when the operation
is completely well-defined and feasible with relative paths
that "one should not absolutize without necessity" seems like
a sound principle.

But allowing that there might be a reason for
--listed-incremental to need the cwd, it's common these days for
the OS to provide getcwd as a syscall to avoid the failure modes
of the old algorithm. Solaris 10 does (this actually isn't
stated in the man page, which has not moved from section 3C to 2,
but is clear in a truss). So it's not obvious why --listed-incremental
would cause the old algorithm to be used on an OS that provides a
working syscall implementation. Is a new autoconf test required?

ZFS users can work around the problem by doing a loopback mount
of the desired snapshot to some other location that isn't beneath
the invisible .zfs directory, and running tar from there.

Chapman Flack
Dept. of Mathematics
Purdue University