On Mon, 27 Oct 2014, 19:54 -0500, John D. Hendrickson and Sara Darnell wrote:
> bugzilla-nore...@freebsd.org wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477
> > 
> > --- Comment #1 from John Marshall <john.marsh...@riverwillow.com.au> ---
> > Confirmed independently on -stable@
> > 
> > https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html
> > 
> > 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.
> > 
> 
> i'll bite very interesting
> 
> is the error on tar or utar ?  i assume you mean on tar -c but be 
> specific

[as per Bug 194477 report] tar -c -C

> is this new or do older version NOT do this?  if so please state the 
>   right and wrong tar versions.

[as per Bug 194477 report] Bug observed in 10.1-RC3.  Fine =< 9.3-RELEASE

> also i need a firm permission basis.  just because you are in same 
> group may not be the same as owning (w/respect to utar, not tar) and 
> if your using any "kernel extended permissions" (tar obviously uses 
> only unix file security / bits.  it stores file perms also user # in 
> tar header)

Specific permissions documented in Bug 194477 report.  Error is
triggered if process running tar -c -C <dir> . does not have +r access
to the parent of the directory <dir>.  If the tar process has +x access
only to the parent of the -C <dir> (and full access to <dir>) then the
tar archive is written correctly but tar exits with an error because it
cannot read <dir>'s parent directory.  It looks like the earlier tar
used chdir() to walk back up the tree at the end whereas the current tar
uses openat() and tries to openat() the parent of <dir> after the <dir>
tree has been processed - and fails due to lack of +r access.

> i don't see any follow-ups just the initial comlaint, did this 
> complain expire ?

Nobody has picked this up yet but another user on -stable@ confirmed the
problem and provided an even simpler test case.

-- 
John Marshall

Attachment: pgp0Gpvl553TK.pgp
Description: PGP signature

Reply via email to