Re: euidaccess() vs non suid /bin/sh (Re: dash test -w oddities)

[Oleg Verych <olecom@flower.upol.cz>]

> >I wonder even more why access() syscall isn't a solution, because
> >/bin/sh isn't set-uid by definition.
> >
> >#/bin/cc glibc/sysdeps/posix/euidaccess.c
> >[...]
> >    /* If we are not set-uid or set-gid, access does the same.  */
> >    return access (path, mode);
> >[...]
> >#end_cc
> 
> It might be run from a setuid program.

Scripts with '#!/bin/sh' cannot be set-uid,

#man system (debian):

       Do  not  use  system()  from a program with set-user-ID or set-group-ID
       privileges, because strange values for some environment variables might
       be  used  to subvert system integrity.  Use the exec(3) family of func-
       tions instead, but not execlp(3) or execvp(3).  system() will  not,  in
       fact,  work  properly  from  programs  with set-user-ID or set-group-ID
       privileges on systems on which /bin/sh is bash version 2, since bash  2
       drops  privileges  on startup.  (Debian uses a modified bash which does
       not do this when invoked as sh.)

#end

Programs being designed to be set-uid should have proper setup for
proper running any external command. No?

The call euidaccess() makes sense now, just asking to make clear this
mess a bit.
____