Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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: Fri, 3 Sep 2004 09:22:46 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Christian Weinberger <christian DOT weinberger AT directbox DOT com>
cc: cygwin AT cygwin DOT com
Subject: Re: env -i specialities on cygwin
In-Reply-To: <loom.20040903T131145-156@post.gmane.org>
Message-ID: <Pine.GSO.4.61.0409030918340.28876@slinky.cs.nyu.edu>
References: <loom DOT 20040903T131145-156 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1094217766=:28876"
X-Scanned-By: MIMEDefang 2.39

---559023410-684387517-1094217766=:28876
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

On Fri, 3 Sep 2004, Christian Weinberger wrote:

> If one want´s to start a new process without an environment, env -i will be
> the choice.
> In the cygwin enviroment this leads to problems if /bin or /usr/bin are not
> added to the PATH in the new process. In this case the cygwin1.dll is not
> in the path and will not be found be the process that just tries to start.
> This is true for all other DLLs that may be used by the cygwin executable.

Yes, that's the way Windows works.  You *have* to have /bin in your PATH
if you want the Windows dynamic loader to find your DLL.

> There are two options to avoid this:
> 1) Modify all shell scripts that use env -i to include /usr/bin in the PATH
> when porting appications to cygwin. This means lots of manual work since
> shell scripts are often not considered to be dynamic in autoconf/automake
> runs.
> 2) Modify the env binary to always include /usr/bin to the path, even if
> the -i switch is specified. But this will not just allow access to the DLLs
> but to all executables in the same directory. This may raise security
> problems.

Option 2 looks like one that follows the principle of least surprise.
Frankly, I don't see how this raises security problems, as the executables
can always be accessed directly via /bin/blah.exe or /usr/bin/blah.exe
anyway...

> A third solution would be to have all cygwin DLLs in a separate directory
> where no executables reside. But this would be a more dramatic change to
> the distribution.

If you want better security (i.e., protection from malicious scripts), use
chroot.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

---559023410-684387517-1094217766=:28876
Content-Type: text/plain; charset=us-ascii

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/
---559023410-684387517-1094217766=:28876--