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 _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
