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

[Theodoros V. Kalamatianos]

On Sun, 30 Oct 2005, Paul Eggert wrote:

> "Theodoros V. Kalamatianos" <address@hidden> writes:
>
> > I have built coreutils-5.92 on my system (Linux-2.6.11.6/i686,
> > glibc-2.3.3CVS) and was testing the build when I came up with a failed
> > test for tests/cp/fail-perm. The testsuite is run as root.
> > ...
> > open("D/a", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY, 0666) = 0
> > utimes("/proc/self/fd/0", NULL)         = -1 EACCES (Permission denied)
>
> You're saying that you're running as root?  So, on your host root
> doesn't have the ability to set the time on "/proc/self/fd/0"?  That
> sounds a bit strange.  Root should be able to do anything, right?

Actually, for this particular test the testsuite uses the "nobody" user to 
run. But I have verified that the file is indeed owned by nobody and that 
the file permissions allow it to be touched. But I just tried the 
following:

# su nobody -c 'touch --version; touch a && echo OK'
touch (coreutils) 5.2.1
Written by Paul Rubin, Arnold Robbins, Jim Kingdon, David MacKenzie, and Randy 
Smith.

Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
OK

which is as it should. But the following fails:

# su nobody -c '/usr/src/RPM/BUILD/coreutils-5.92/src/touch --version; 
/usr/src/RPM/BUILD/coreutils-5.92/src/touch a && echo OK'
touch (GNU coreutils) 5.92
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, Arnold Robbins, Jim Kingdon, David MacKenzie, and Randy 
Smith.
/usr/src/RPM/BUILD/coreutils-5.92/src/touch: setting times of `a': Permission 
denied

> Can you reproduce this problem with a small C program?  Something like
> this.  Please run it as root, in the same directory, etc.  You can use
> strace to verify that it has the same system calls.
>
> #include <fcntl.h>
> #include <stdio.h>
> #include <sys/time.h>
> #include <unistd.h>
>
> int
> main (void)
> {
>  close (0);
>  if (open ("D/a", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY, 0666) != 0)
>    perror ("open");
>  else if (utimes ("/proc/self/fd/0", 0) != 0)
>    perror ("utimes");
>  return 0;
> }

That's interesting:

# su nobody -c ./test
utimes: Permission denied

It fails, as does the following:

#include <fcntl.h>
#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>

int
main (void)
{
    fprintf(stderr,"stdin fd: %i\n", fileno(stdin));
    if (freopen ("D/a", "w", stdin) == 0) {
        perror ("freopen");
        return 1;
    }
    fprintf(stderr,"stdin fd: %i\n", fileno(stdin));

    if (utimes ("/proc/self/fd/0", 0) != 0)
        perror ("utimes");
    return 0;
}

...and the following, run as nobody:

sh-3.00$ ls -al /proc/self/fd/0
ls: /proc/self/fd/0: Permission denied
sh-3.00$ ls -al /proc/self/fd/1
ls: /proc/self/fd/1: Permission denied
sh-3.00$ ls -al /proc/self/fd/2
ls: /proc/self/fd/2: Permission denied
sh-3.00$ ls -al /proc/self/
ls: /proc/self/: Permission denied
sh-3.00$ ls -al /proc/
ls: /proc/: Permission denied
sh-3.00$ ls -al /
ls: /: Permission denied

which after carefull consideration leads to a big fat OUCH!:

# ls -ald /proc
dr-xr-x---  240 root adm 0 Oct 24 23:48 /proc/

My usual non-root user just happens to be in the adm group so everything 
worked just fine for him. But nobody is not, so...

It seems that my distribution (Mandrake 10.1) in the high security mode 
restricts access to /proc, because there is no way I'd chown anything to 
adm - I am not even sure what that group is supposed to be for.

Although I do consider this to be my own problem, I think it is somewhat 
stupid to reopen the file via stdin, as does the current touch code, 
exactly for stupid cases like mine. It just adds one more place where 
things could break and for what ? One less file descriptor ?

Btw, it seems that the problem is caused by glibc using /proc to translate 
file descriptors to files. I just saw the relative code and it's 
essentially an sprintf(str, "/proc/self/fd/%i", fd)... although I can't 
see how else this could be managed on linux...

I'll just stick with good, old coreutils 5.2.1 for now. I am not in the 
mood to have random scripts and utilities fail on me right now, and 
tackling the whole Mandrake "security" system is out of the question - the 
damn thing is complicated as hell with lots of hard-wired stuff. I still 
haven't be able to "convince" it that the linux SAK (Alt-SysRq) hotkey 
should be accessible... I change the setting and after a few minutes it 
just changes back...talk about security vs. usability...


Regards,

Theodoros Kalamatianos