[Bug-tar] CHOWN_MODIFIES_SYMLINK causes unexpected results

[Howell, Daniel A]

This is against GNU tar 1.15.1:

If tar is built with the configuration option CHOWN_MODIFIES_SYMLINK
(which the configure script automatically defines for any cross-compiled
system) the following problems can occur:

 1) If HAVE_LCHOWN is not set, then extracting a symbolic link will
cause the underlying file to get the ownership of the link in the tar
file, if the link is extracted after the file.

 2) Extracting a device node will cause the corresponding device to be
opened for read (and then write, if the read fails), which could cause
unexpected device actions.

The reason for this is the rpl_chown function in lib/chown.c, which
attempts to emulate the proper behavior of chown when chown does not
follow symlinks, by opening the file and doing an fchown on the file
descriptor.  In config.h, chown is #define'd to rpl_chown.

However, in the case of lchown not being available, this is not the
behavior we want.  We want the behavior of the system chown in this
case, not rpl_chown.  (This problem is hinted to in the FIXME comment
above set_stat in src/extract.c.)

Also, when rpl_chown is called on a device node, the open call causes
the underlying device to get opened, which in some cases is undesirable
(in my case there was a bug in the device driver which caused a
segfault, but even non-buggy drivers could cause undesirable things to
happen when being opened unexpectedly).

I thought about doing an #undef chown in src/extract.c, but this may
break the CHOWN_FAILS_TO_HONOR_ID_OF_NEGATIVE_ONE config option.

Maybe the correct thing to do is create a rpl_lchown function in
lib/chown.c to deal with the -1 issue, call the rpl_lchown from
extract.c even on files that are not symbolic links, and have rpl_lchown
call chown if HAVE_LCHOWN is not defined and CHOWN_MODIFIES_SYMLINK is.

This will not work if both HAVE_LCHOWN and CHOWN_MODIFIES_SYMLINK are
undefined, but in that case the system provides no way to modify
ownership of a symlink.  This configuration combination probably doesn't
happen in real life.

Finally, I thought it might be a bug that configure always defines
CHOWN_MODIFIES_SYMLINK for cross-compiled systems, but I couldn't think
of anyway to properly detect the correct answer.  But these days the
likelihood is that chown does follow symlinks, so maybe the default
should be changed?  Or perhaps it should be only defined if lchown is
not available, since the availability of lchown would seem to imply
chown following symlinks.

Dan Howell