delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/04/23/01:44:46

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 22 Apr 2002 22:44:27 -0700 (PDT)
From: Richard Troy <rtroy AT sciencetools DOT com>
X-X-Sender: <rtroy AT fs1 DOT in>
To: <cygwin AT cygwin DOT com>
Subject: Re: The Cygwin Server Daemon - VERY LONG
In-Reply-To: <Pine.LNX.4.33.0204221255450.9968-100000@fs1.in>
Message-ID: <Pine.LNX.4.33.0204222205060.9968-100000@fs1.in>
MIME-Version: 1.0


Hi All,

when I asked:

> + Regarding my own hopeful use someday: What is a reasonable approach to 
>   adding the honoring of the setuid (and guid) bit(s) in image execution?
> 
>   I take it that cygwin1.dll needs to be changed, but cygwin1.dll seems to 
>   be built of little bits of source code scattered about. I imagine that 
>   in there somewhere is code that forks off a process to run a new image 
>   that the user wants run. And I imagine that somewhere in there, where 
>   the file access occurrs to bring in the executable image, there's a 
>   place where new code should be inserted to test the suid bits and, if 
>   the bit is set, a call to change security context into the file owner 
>   should occurr. Comments _please._ In particular, does anyone know the
>   module name I should be mucking with? What about the call to change
>   context to the file owner? These pointers will help save me a lot of 
>   time and are greatly appreciated.

I have noticed the source src/winsup/cygwin/exec.cc - seems like it might
be the right place. However, it has the following comment:

/* This is called _execve and not execve because the real execve is 
   defined in libc/posix/execve.c.  It calls us.  */

Not sure just where that was, I was surprised at this result!

$ find . -iname execve.c
./newlib/libc/posix/execve.c
./newlib/libc/sys/mmixware/execve.c
./newlib/libc/sys/sysmec/execve.c
./newlib/libc/sys/sysnecv850/execve.c

And, libc/posix/execve.c said:

/* This and the other exec*.c files in this directory require
   the target to provide the _execve syscall.  */

$ ls newlib/libc/posix/exec*
execl.c  execle.c  execlp.c  execv.c  execve.c  execvp.c

...Hmmm... I've mostly been a consumer of Unix/posix exec calls... It 
seems reasonable that there'd be a translation layer between the posix 
exec call formats and the Windows OS calls. I take it that the posix 
routines call the appropriate routine in src/winsup/cygwin/exec.cc, which 
is responsible for the appropriate behavior under cygwin?

Commentary? Anybody know where there's a reasonably concise write up of 
this strategy? 

Thanks in advance,
Richard


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019