[PATCH] Cygwin: add secure_getenv

Yaakov Selkowitz yselkowi@redhat.com
Tue Feb 19 16:58:00 GMT 2019


On Tue, 2019-02-19 at 12:59 +0100, Corinna Vinschen wrote:
> On Feb 19 12:43, Corinna Vinschen wrote:
> > On Feb 18 23:09, Yaakov Selkowitz wrote:
> > > Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
> > > ---
> > > This is being used more frequently.  Since we don't have Linux capabilities,
> > > setuid/setgid is the only condition we have to check.
> > 
> > I'm not sure this is right.  The Linux man page claims
> > 
> > "Secure execution is required if one of the following conditions was
> >  true when the program run by the calling process was loaded: [...]"
> > 
> > Do we ever have this situation?  We don't have any capability to make
> > real and effective user ID different at process startup.  But from that
> > description it seems secure_getenv does not trigger secure mode if the
> > process calls seteuid() or setreuid() later in the process.
> > 
> > I ran this STC as root under Linux:
> > 
> > # cat > sec-getenv-test.c <<EOF
> > #define _GNU_SOURCE
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <errno.h>
> > #include <string.h>
> > #include <sys/types.h>
> > #include <unistd.h>
> > 
> > int main ()
> > {
> >   char *env;
> > 
> >   env = secure_getenv ("HOME");
> >   printf ("vor seteuid: HOME=%p <%s>\n", env, env ?: "");
> >   if (seteuid (74) < 0)
> >     printf ("seteuid: %d <%s>\n", errno, strerror (errno));
> >   else
> >     {
> >       env = secure_getenv ("HOME");
> >       printf ("nach seteuid: HOME=%p <%s>\n", env, env ?: "");
> >     }
> >   return 0;
> > }
> > EOF
> > # gcc -g -o sec-getenv-test sec-getenv-test.c
> > # ./sec-getenv-test
> > vor seteuid: HOME=0x7fff17a04ea2 </root>
> > nach seteuid: HOME=0x7fff17a04ea2 </root>
> 
> I also tried to run secure_getenv after fork, like this:
> 
>   seteuid()
>   if (fork () == 0)
>     env = secure_getenv ("HOME");
> 
> but it still returns a valid value.
> 
> So I wonder if secure_getenv isn't just a synonym for getenv
> in our case.

Or could it be the STC?  glibc's test is a bit more complicated:

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/tst-secure-getenv.c;hb=HEAD

And, looking now, FWIW gnulib's implementation is practically similar:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/secure_getenv.c;hb=HEAD

So if there is something wrong with the patch, then AFAIK gnulib is
wrong too.  Eric?

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.




More information about the Cygwin-patches mailing list