X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=hEva2RG
	PzeU6HObPvfNRj5Nax5L/IIccG1msRqcQzGjWwr3PXsFnySi+RG2y76Eh3X/h9iM
	+46/XidREi5Ah5y+cTij2zTqqpTcJpW42qUPCkCaMvIf2Yq7yFZ99lHgz2FKR3Lb
	z68SicKazA+VQ0wOlYUbPSB6zbZe+tV44kIg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=W+D/oV4yjuIms
	bx7FN4bwRVmrF8=; b=HQL9aKO8rK3+TOZO+hUi5jVJmvD/DqW/UrV4iuYZfZzeV
	/xWNlf5Aav2RmtCXarJsH8yY6k05qhXlucfjRhulPwmH2nId/kk1sLUxSFhzrfp5
	ZIdfCV2tQIf1NJu1LTT9496nc0N4Jz/TKukND+oM9dAhuEkFbiIKQ3yF1IMJF0=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=moss AT cs DOT umass DOT edu, sk:mosscs, D*cs.umass.edu, sk:moss AT cs
X-HELO:	mail-wm0-f49.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SKhBuOQkonWahEXXYS/GzJrXywXG/sfWi6M9h1taxWw=; b=IwJDlYIFqRL+725LsrQ/8epe+RHMSXdYuf0+fFzKrFh/kAXXxroIJP+C7scUwAGMuS KIfEeWX9aT+n4riHeQ+p++iN30WxmoDZZ0buMwi1TVaDu7mUeBY+gZ16UtzGL1YF77RQ /2Tq9a59sU+f/Od2vUgSiisaF/IBKXedBxHeP++0CSnYrOdl0t3/1LWptJeMFFK3/n7u M6uU/Zks7z/+TYH3w/eROsWDovE/0Esz87jUt1vEW8vuLDTqK1FhWEkuzsT9aJlg91ZL kDengMTWFI2zQMsUBRc/XvqPdF2YP3U1wSfR6y1n825lx05r+i0S9UfGHLUqrK9iVGld IhIQ==
X-Gm-Message-State:	AKaTC02AIUYoDwF2WBsNEgTNNqTTysUY57qi1bCDUOMA4ELYQ++hwZvx1989lE0rcko8IhqX8s7iIGo0oqY3gg==
X-Received:	by 10.28.9.80 with SMTP id 77mr25227902wmj.68.1480435305587; Tue, 29 Nov 2016 08:01:45 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<98eb08bf-5012-fe14-b10c-241b427c4366@cs.umass.edu>
References:	<CAOTD34ZFH5E3r3AuDOXctss46e1hoU2f9pwE1mt4L674J2Ak_A AT mail DOT gmail DOT com> <20161117140012 DOT GA23664 AT calimero DOT vinschen DOT de> <CAOTD34Y9TRq2Qq8Mn2awTf9SCgz0qnbBa-a117pkSEvz9gaHKQ AT mail DOT gmail DOT com> <98eb08bf-5012-fe14-b10c-241b427c4366 AT cs DOT umass DOT edu>
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Tue, 29 Nov 2016 17:01:44 +0100
Message-ID:	<CAOTD34bPTUkKiHSmqvczz6juePBD=6PyzabDFfHpYL_cFzyf9A@mail.gmail.com>
Subject:	Re: Retrieving per-process environment block?
To:	moss AT cs DOT umass DOT edu, cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On Tue, Nov 29, 2016 at 3:28 PM, Eliot Moss <moss AT cs DOT umass DOT edu> wrote:
> On 11/29/2016 8:26 AM, Erik Bray wrote:
>>
>> On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen
>> <corinna-cygwin AT cygwin DOT com> wrote:
>>>
>>> On Nov 17 14:30, Erik Bray wrote:
>>>>
>>>> Hi all,
>>>>
>>>> For a quick bit of background, I'm working on porting the highly
>>>> useful psutil [1] Python library to Cygwin.  This has proved an
>>>> interesting exercise, as much of the functionality of psutil works on
>>>> Cygwin through existing POSIX interfaces, and a handful of
>>>> Linux-specific interfaces as well.  But there are some bits that
>>>> simply don't map at all.
>>>>
>>>> The one I'm struggling with right now is retrieving Cygwin environment
>>>> variables for a process (under inspection--i.e. not listing a
>>>> process's environment from within that process which is obviously
>>>> trivial).
>>>>
>>>> I've looked at every route I could conceive of but as far as I can
>>>> tell this is currently impossible.  That's fine for now--I simply
>>>> disable that functionality in psutil.  But it is unfortunate, though,
>>>> since the information is there.
>>>>
>>>> There are a couple avenues I could see to this.  The most "obvious"
>>>> (to me) being to implement /proc/<pid>/environ.
>>>>
>>>> I would be willing to provide a patch for this if it would be
>>>> accepted.  Is there some particular non-obvious hurdle to this that it
>>>> hasn't been implemented?  Obviously there are security
>>>> implications--the /proc/<pid>/environ should only be readable to the
>>>> process's owner, but that is already within Cygwin's capabilities, and
>>>> works for other /proc files.
>>>
>>>
>>> Patch welcome.  Implementing this should be fairly straightforward.
>>> The only hurdle is winsup/CONTRIBUTORS ;)
>>
>>
>> Thanks--I went to go work on this finally but it turns out not to be
>> straightforward after all, as the process's environment is not shared
>> in any way between processes.
>>
>> I could do this, if each process kept a copy of its environment block
>> in shared memory, which would in turn have to be updated every time
>> the process's environment is updated.  But I don't know what the
>> impact of that would be performance-wise.
>
>
> Sorry, no advice getting around this, but a thought about why it may have
> been hard -- it can be a security hole.  Given Windows' complex access
> rights,
> how would one determine which processes should reasonably have access to
> another process's environment variables?  Maybe Windows decided to punt the
> issue.  (I don't know anything about this at all - as I said, just a
> thought.)
>
> A question: Are there any Windows tools that can do this?  If so, you might
> be able to trace them to find what they do.

Hi,

Thanks for the reply.  The issue here isn't getting the Windows
process environment--that can be done, albeit trickily [1].  While
it's true there are security implications, in this case that is
handled at the OpenProcess call required to obtain a handle to the
process.  It's true you can't just read the environment from a process
you don't have permission to.

The issue here though is reading the Cygwin process's environment
which is separate from its Windows environment, and the above
technique is inapplicable.

The easiest way, as I suggested, would be to keep a copy of each
process's Cygwin environment in shared memory as is the case with the
pinfo struct.  I just don't know if it's worth the effort for this
relatively narrow case (it's no so much effort to implement, I just
worry what performance impacts that could have, though I suppose I
could just try it and see...)


[1] https://theroadtodelphi.com/2012/06/09/getting-the-environment-variables-of-an-external-x86-and-x64-process/

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

- Raw text -