Bug 194477 - 10.1-RC1 tar(1) spurious directory permission error message
Summary: 10.1-RC1 tar(1) spurious directory permission error message
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.1-STABLE
Hardware: Any Any
: Normal Affects Many People
Assignee: Martin Matuska
Depends on:
Reported: 2014-10-20 09:00 UTC by John Marshall
Modified: 2019-06-06 09:33 UTC (History)
3 users (show)

See Also:
koobs: mfc-stable11+
koobs: mfc-stable12+


Note You need to log in before you can comment on or make changes to this bug.
Description John Marshall 2014-10-20 09:00:57 UTC
I don't know if tar(1) is the culprit or an innocent bystander but this is what I am seeing on 10.1-RC1 (r272468 amd64). The archive appears to be written properly prior to generation of the error message.

Although the user is permitted to traverse the parent directory and read the -C directory, tar(1) emits the complaint if the parent directory is not also readable. Filesystem is UFS.

  $ tar -czf dtt.tgz -C /data/tftp/thlan .
  tar: .: Unable to continue traversing directory tree: Permission denied
  tar: Error exit delayed from previous errors.

  $ ls -ld /data /data/tftp /data/tftp/thlan
  drwxr-xr-x  33 root  wheel  1024  2 Sep 20:13 /data
  drwxr-x--x   4 root  wheel   512 23 Apr 09:00 /data/tftp
  drwxr-x--x   3 john  wheel   512 23 Apr 10:28 /data/tftp/thlan

  # chmod o+r /data/tftp

  $ tar -czf dtt.tgz -C /data/tftp/thlan .

I haven't played with 10.0 but this behaviour is different to other earlier releases (e.g. 9.3-RELEASE doesn't do this).
Comment 1 John Marshall 2014-10-22 23:33:10 UTC
Confirmed independently on -stable@


The scenario of traversal-only access to the parent directory is common in a situation where the directory contains per-user subdirectories, and each user has no business knowing about any subdirectory but his own.

The archive generated is fine, the user has full permission to the directory being archived, but tar(1) exits with an error status.

I regard this regression as a bug.
Comment 2 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:20 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 3 Glen Barber freebsd_committer 2015-07-07 15:45:16 UTC
John, can you verify if this issue persists on recent 10.2-PRERELEASE builds?
Comment 4 John Marshall 2015-07-07 21:51:04 UTC
(In reply to Glen Barber from comment #3)

Still a problem on recent 10-STABLE.
  FreeBSD 10.1-STABLE #0 r284296: Sat Jun 13 06:42:48 AEST 2015

Building r285255 now. Will test and report.
Comment 5 John Marshall 2015-07-08 04:05:48 UTC
(In reply to Glen Barber from comment #3)

Still emits the error on:
  FreeBSD 10.2-PRERELEASE #0 r285255: Wed Jul  8 12:50:45 AEST 2015

Please note that the cause of this issue was tracked down by Peter Jeremy in the -stable@ thread link included in Commment 1.

Thank you for looking at this bug.
Comment 6 andrew 2019-03-29 02:33:37 UTC
This bug still exists in 12-stable.
Comment 7 andrew 2019-06-05 10:07:10 UTC
This should now be fixed (in 10-stable as well as 11-stable and 12-stable) by the MFC of r347990 (see upstream PR #1167).
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-06 09:31:39 UTC
Assign to committer that resolved. Thank you for the resolution information Andrew