Re: coreutils-5.92 - tests/cp/fail-perm fails when run as root

[Paul Eggert]

"Theodoros V. Kalamatianos" <address@hidden> writes:

> Yeap, that fixes touch alright, so the original bug is now resolved.

Thanks for checking this.  On reviewing this I think it's better to be
even more conservative, so I installed the fix below instead (in both
coreutils and gnulib).  I'll look at your other patches next.

I'm pretty sure that Mandrake's policy of not letting programs look at
/proc/self will break a lot of other software in possibly-subtle ways,
so could you please report it as a bug?  I don't see any reason why a
process shouldn't be able to look at /proc/self/fd.  Certainly glibc
itself uses /proc/self/fd in places other than its implementation of
futimes.

2005-10-30  Paul Eggert  <address@hidden>

        Fix porting problem reported by Theodoros V. Kalamatianos.
        * lib/utimens.c (futimens) [HAVE_WORKING_UTIMES && HAVE_FUTIMES]:
        Don't assume that futimes failing means we must fail.

--- lib/utimens.c       26 Sep 2005 23:01:00 -0000      1.10
+++ lib/utimens.c       30 Oct 2005 21:27:01 -0000
@@ -99,17 +99,15 @@ futimens (int fd ATTRIBUTE_UNUSED,
       if (futimes (fd, t) == 0)
        return 0;
 
-      /* On GNU/Linux without the futimes syscall and without /proc
-        mounted, glibc futimes fails with errno == ENOENT.  Fall back
-        on utimes if we get a weird error number like that.  */
-      switch (errno)
-       {
-       case EACCES:
-       case EIO:
-       case EPERM:
-       case EROFS:
-         return -1;
-       }
+      /* Don't worry about trying to speed things up by returning right
+        away here.  glibc futimes can incorrectly fail with errno ==
+        ENOENT if /proc isn't mounted.  Also, Mandrake 10.0 in high
+        security mode doesn't allow ordinary users to read /proc/self, so
+        glibc futimes incorrectly fails with errno == EACCES.  If futimes
+        fails with errno == EIO, EPERM, or EROFS, it's probably safe to
+        fail right away, but these cases are rare enough that they're not
+        worth optimizing, and who knows what other messed-up systems are
+        out there?  So play it safe and fall back on the code below.  */
     }
 # endif
 #endif