[OpenAFS] Solaris unlink removes AFS mount points

[Renata Maria Dart]

Hi, although such a call can't cause volume corruption it can
nevertheless cause a program to behave incorrectly.  For
example, consider a user program that relies on the documented
behavior of the Solaris unlink system call to remove files but
not directories.  One can argue that this is not a very safe way
to program; however, it is not a hypothetical example.  We
recently upgraded gnu tar (gtar) from 1.13 to 1.13.25 and
encountered exactly this problem (which is the reason for this
report).  Here's the summary of what we found with the new
version of gtar:

> In Solaris a gtar extract operation which crosses an AFS mount
> point will unmount the AFS volume and a new directory will be
> created in its place unless gtar's -k (or --keep-old-files) flag
> is specified.  Here's the relevant piece of a truss of such a
> gtar extract in Solaris (in this example, "rzc_test_test" is the
> target directory for the extract and is an AFS mount point at the
> beginning of the operation):
>
> ...
> mkdir("rzc_test_test", 0755)                 Err#17 EEXIST
> unlink("rzc_test_test")                              = 0
> mkdir("rzc_test_test", 0755)                 = 0
> write(1, " r z c _ t e s t _ t e s".., 19)   = 19
> open64("rzc_test_test/junk", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
> close(4)                                     = 0
> ...
>
> It appears that gtar first attempts to create the
> output directory and then, if that fails because the directory
> exists, it tries to unlink it.  In the case of Solaris, the unlink
> succeeds, so gtar repeats the mkdir and then goes on to populate the
> directory (in this case with a single zero-length file named "junk").

This change in behavior is causing a number of our users very
serious problems.

-Renata

>Date: Tue, 16 Mar 2004 18:39:23 -0500
>From: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>
>Subject: Re: [OpenAFS] Solaris unlink removes AFS mount points
>To: Renata Maria Dart <renata@SLAC.Stanford.EDU>
>Cc: openafs-info@openafs.org
>MIME-version: 1.0
>Content-transfer-encoding: 7bit
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bache.ece.cmu.edu
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
version=2.63
>X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 
2004.3.16.94414
>X-Keywords: 
>
>On Tue, 2004-03-16 at 18:32, Renata Maria Dart wrote:
>> For an ordinary filesystem, the root account has the "appropriate
>> privileges" to unlink directories.  However, root should have no
>> special privileges in AFS filesystems.  So we don't think that AFS 
>> should permit the unlink system call to remove AFS mount points either
>> for root or non-root users.
>
>I would argue there's no reason to worry about it.  Local directories
>require root permission because exercising unlink(2) directly on one
>will damage the filesystem unless done properly (i.e. insure directory
>contains only "." and "..", unlink "." and ".." entries, unlink
>directory).  As an AFS mountpoint is really just a symlink, one cannot
>cause volume corruption by unlinking it directly.
>
>-- 
>brandon s. allbery    [linux,solaris,freebsd,perl]     allbery@kf8nh.com
>system administrator      [WAY too many hats]        allbery@ece.cmu.edu
>electrical and computer engineering, carnegie mellon univ.         KF8NH
>

 Renata Dart                         | renata@SLAC.Stanford.edu  
 Stanford Linear Accelerator Center  |    
 2575 Sand Hill Road, MS 97          | (650) 926-2848 (office)
 Stanford, California   94025        | (650) 926-3329 (fax)