bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash does not skip own files in PATH that have execute bit not set.


From: carlo
Subject: bash does not skip own files in PATH that have execute bit not set.
Date: 11 Sep 2003 21:11:21 -0000

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  -g -O2
uname output: Linux ansset 2.6.0-test4-debug #1 Thu Sep 4 03:24:03 CEST 2003 
i686 athlon i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
        Normal behaviour of bash is to execute the first
        matching file in PATH that *can* be executed.
        
        For example:

        ~>mkdir testa
        ~>mkdir testb
        ~>echo 'echo "testa"' > testa/foo
        ~>echo 'echo "testb"' > testb/foo
        ~>whoami
        carlo
        ~>sudo chown root testa/foo
        ~>sudo chmod 500 testa/foo
        ~>chmod 755 testb/foo
        ~>PATH=$PWD/testa:$PWD/testb ~/c/bash-2.05b/bash -c foo
        testb

        However, it doesn't do this in all cases
        because it *thinks* it can execute a file
        with mode 655 that it owns, what is not the case.

Repeat-By:
        Make sure that testa and testb do not exist.
        ~>mkdir testa
        ~>mkdir testb
        ~>echo 'echo "testa"' > testa/foo
        ~>echo 'echo "testb"' > testb/foo
        ~>chmod 655 testa/foo
        ~>chmod 755 testb/foo
        ~>PATH=$PWD/testa:$PWD/testb ~/c/bash-2.05b/bash -c foo
        /home/carlo/c/bash-2.05b/bash: line 1: /home/carlo/testa/foo: 
Permission denied

Fix:
        The origin of this bug is in findcmd.c lines 127 through 138:

          /* If we are the owner of the file, the owner execute bit applies. */
          if (current_user.euid == finfo.st_uid && X_BIT (u_mode_bits 
(finfo.st_mode)))
            return (FS_EXISTS | FS_EXECABLE);

          /* If we are in the owning group, the group permissions apply. */
          if (group_member (finfo.st_gid) && X_BIT (g_mode_bits 
(finfo.st_mode)))
            return (FS_EXISTS | FS_EXECABLE);

          /* If `others' have execute permission to the file, then so do we,
             since we are also `others'. */
          if (X_BIT (o_mode_bits (finfo.st_mode)))
            return (FS_EXISTS | FS_EXECABLE);

         This should be changed into:

         /* If we are the owner of the file, the owner execute bit applies. */
         if (current_user.euid == finfo.st_uid)
           return  X_BIT (u_mode_bits (finfo.st_mode)) ? (FS_EXISTS | 
FS_EXECABLE) : FS_EXISTS;

         /* Otherwise, if we are in the owning group, the group permissions 
apply. */
         if (group_member (finfo.st_gid))
           return  X_BIT (g_mode_bits (finfo.st_mode)) ? (FS_EXISTS | 
FS_EXECABLE) : FS_EXISTS;

         /* Otherwise, if `others' have execute permission, the other 
permissions apply. */
         return X_BIT (o_mode_bits (finfo.st_mode)) ? (FS_EXISTS | FS_EXECABLE) 
: FS_EXISTS;

If you really have to meantion names in ChangeLogs or something,
then not only mention me but also Bill Moseley <moseley@hank.org>.
He reported this as a bug to me for `GNU which', of which I am the author.

That this is a bug does not only follow from the logic
given in the first section, but also from the comment in
the current code:

          /* If `others' have execute permission to the file, then so do we,
             since we are also `others'. */

That is clearly NOT true.

Carlo Wood.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]