And one more round, after thinking about it last night.

It occurred to me that, now that the assessment of the issue has changed
from the content of symlinks to the act of *following* symlinks, that the
protections mentioned in the proposal could be applied as default behavior,
and all this can be distilled/simplified further.

These corner cases shouldn't appear in normal archives, even for
backup/restore operations, so they can be errors by default.  Even
pkg_add(8) won't need to use the --insecure option in this proposal, since
binary packages won't contain such things.

Revised proposal follows:

1. Create an "insecure mode" flag in pax, which will actually extract,
   rather than skip, the following types of entries (and suppress the
   related warnings?).  (Flag already available:  --insecure)

2. For each entry being extracted, warn and skip file if any intervening
   path component is a symlink in the filesystem.  (This catches both extant
   symlinks *and* those created by pax.)

   If the entry's full path is an extant symlink, however, don't warn; do
   standard unlink-and-create logic.  Basically, don't do the lstat(2)
   check on the last path component.  (This would have to be tested as to
   whether it DTRT for non-plain-files, e.g. directories and device nodes,
   that replace symlinks in the filesystem.  The idea is that even a
   directory that exactly matches an extant symlink would simply replace the
   symlink with a directory safely.)

3. If a file is encountered in the archive which contains "../" in its
   pathname, warn and skip file.

-- 
-- Todd Vierling <tv@pobox.com>