Re: [PATCH] Fix system() behaviour when parameter is NULL

[Ignatios Souvatzis <is%netbsd.org@localhost>]

On Thu, Aug 28, 2008 at 08:15:40PM +0200, mouss wrote:
> Andy Shevchenko wrote:
>> The ISO/IEC 9899:1999 describes in 7.20.4.6 behaviour of the system() when 
>> its
>> parameter is NULL. So, we should check a presence of a command interpreter
>> instead of returning 1.
>> ---
>>  lib/libc/stdlib/system.c |   11 +++++++++--
>>  1 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/libc/stdlib/system.c b/lib/libc/stdlib/system.c
>> index 4cc3cbe..2b729b5 100644
>> --- a/lib/libc/stdlib/system.c
>> +++ b/lib/libc/stdlib/system.c
>> @@ -64,8 +64,15 @@ system(command)
>>      const char *argp[] = {"sh", "-c", NULL, NULL};
>>      argp[2] = command;
>>  -   if (command == NULL)            /* just checking... */
>> -            return(1);
>> +    /*
>> +     * ISO/IEC 9899:1999 in 7.20.4.6 describes this special case.
>> +     * We need to check availability of a command interpreter.
>> +     */ +   if (command == NULL) {
>> +            if (access(_PATH_BSHELL, R_OK | X_OK) == 0)
>> +                    return 1;
>> +            return 0;
>> +    }
>>      sa.sa_handler = SIG_IGN;
>>      sigemptyset(&sa.sa_mask);
>
>
> Is using access() a "clean" way? access(2) says:
>
> "access() is a potential security hole and should never be used."

Well, access() only tells you, what's true at access() time, not what's
true later when you actually open() or exec() the file - so when you use
it for an access permission check and later use the file as a
priviledged process that succeeds anyway, you might be bitten by
a race condition. (e.g.: user let's you access() a file that he's allowed
to use, then quickly moves in a symlink to a root-only program and you
execute/open that as root). In this scenario, the correct method would
be to open() or exec() the program as an unpriviledged user in the first
place.

However, as same is the case with the "command == NULL" case above (it's
also no replacement for calling the interpreter to execute the script),
you don't give up security that you would have otherwise.

Regards,
        -is
-- 
seal your e-mail: http://www.gnupg.org/