[OpenAFS] Solaris unlink removes AFS mount points

[Derrick J Brashear]

if it's really gafs_remove doing it, perhaps this is the right answer?
(against the head, not 1.2.x, and i haven't tried it, i'm just guessing)

it should be that afs_remove has no business removing a mount point on any
platform and so this is safe.

--- src/afs/VNOPS/afs_vnop_remove.c   15 Jul 2003 23:14:30 -0000      1.25
+++ src/afs/VNOPS/afs_vnop_remove.c   17 Mar 2004 20:21:41 -0000
@@ -279,6 +279,15 @@
 #endif
        return code;
     }
+
+    if (adp->mvstat == 1) {
+#ifdef  AFS_OSF_ENV
+       afs_PutVCache(adp);
+       afs_PutVCache(tvc);
+#endif
+       return EISDIR;
+    }
+
     if (strlen(aname) > AFSNAMEMAX) {
        afs_PutFakeStat(&fakestate);
 #ifdef  AFS_OSF_ENV


On Wed, 17 Mar 2004, Renata Maria Dart wrote:

> 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)
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>