Re: Feature (bug) in access() and/or /hurd/auth

[Jon Arney]

Marcus Brinkmann wrote:

> 
> It should definitely fail with ELOOP.

I aggree.

> 
> The bug is probably in glibc/sysdeps/mach/hurd/access.c, which is the
> implementation of access() on the Hurd.  That would be a good place to
> start your research.  (Could also be in the file name lookup itself, or in
> the way it is used).

The problem appears to be in glibc/hurd/hurdlookup.c.  It seems to
me that in the case of symbolic links (and other 'special' files)
Hurd's 'dir_lookup' fuction asserts FS_RETRY_MAGICAL, a name I'm not
altogether comfortable with :)

Here is the 'gdb' output from the test program:

GNU gdb 5.1.0.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-gnu"...
Attaching to program `/bin/gcc', pid 49
Reading symbols from /hurd/lib/libc.so.0.2...done.
Loaded symbols for /hurd/lib/libc.so.0.2
Reading symbols from /lib/ld.so...done.
Loaded symbols for /lib/ld.so
Reading symbols from /hurd/lib/libmachuser.so.1...done.
Loaded symbols for /hurd/lib/libmachuser.so.1
Reading symbols from /hurd/lib/libhurduser.so.0.0...done.
Loaded symbols for /hurd/lib/libhurduser.so.0.0
[Switching to thread 49.1]
(gdb) bt
#0  0x0105a28d in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:118
#1  0x011906e7 in __auth_user_authenticate (handle=53, rendezvous=12428,
    rendezvousPoly=20, newport=0x1021778)
    at
/hurd/src/stage1/glibc-2.2.1/obj/hurd/RPC_auth_user_authenticate.c:133
#2  0x01107615 in reauthenticate (which=1, result=0x1021778)
    at ../sysdeps/mach/hurd/access.c:43
#3  0x011077e8 in init_port (which=1, operate=0x1020df4)
    at ../sysdeps/mach/hurd/access.c:63
#4  0x01047bd4 in __hurd_file_name_lookup_retry
(use_init_port=0x102174c,
    get_dtable_port=0x105d5a0 <__getdport>, lookup=0x119a960
<__dir_lookup>,
    doretry=FS_RETRY_MAGICAL,
    retryname=0x10212ec "/hurd/i586-gnu/bin/i586-gnu/2.95.3/as",
flags=0,
    mode=0, result=0x1021748) at hurdlookup.c:376
#5  0x01047330 in __hurd_file_name_lookup (use_init_port=0x102174c,
    get_dtable_port=0x105d5a0 <__getdport>, lookup=0x119a960
<__dir_lookup>,
    file_name=0x8060d91 "hurd/i586-gnu/bin/i586-gnu/2.95.3/as", flags=0,
    mode=0, result=0x1021748) at hurdlookup.c:97
#6  0x01107c96 in __access (
    file=0x8060d90 "/hurd/i586-gnu/bin/i586-gnu/2.95.3/as", type=1)
    at ../sysdeps/mach/hurd/access.c:112

SNIP...lots of not-very-interesting-stuff...

In __hurd_file_name_lookup_retry, there seems to be a test for recursion
in the form of:

      switch (doretry)
        {
        case FS_RETRY_REAUTH:
          if (err = reauthenticate (*result))
            return err;
          /* Fall through.  */

        case FS_RETRY_NORMAL:
#ifdef SYMLOOP_MAX
          if (nloops++ >= SYMLOOP_MAX)
            return ELOOP;
#endif
---SNIP---
        break;
        case FS_RETRY_MAGICAL:

Herein lies the problem as I read it.  The first case is covered by the
ELOOP check since it's a 'fall through' and the second case is covered.
Any other cases (for instance FS_RETRY_MAGICAL) are not covered by this
test.

I would therefore propose that the SYMLOOP_MAX test be moved outside the
'switch' so that _ALL_ cases will be covered.  I'm a little afraid of
this
solution because I'm not sure what the original intent was in omitting
this
case from the test.  I'll give it a try and see how it works out.

This does, however, lead to one architectural question whose answer I am
not sure about.  A cunning user (read as hacker) might think it's a good
idea to blast '/hurd/auth' or other hurd translators using direct mach
port code (for instance that taken from a buggy version of libc) and
apply a denial of service style attack on the hurd translators.  While
I realize that this is probably not priority one in the hurd right now,
it might be worthwhile to spend some time thinking of solutions to this
problem.

-- 
------------------------------------------------------------------------
Jonathan S. Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------