X-Recipient: archive-cygwin@delorie.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:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=CC3/gi1VEzkGHLOL
	FCMmNII59suHJaxpYRuw8MB1NmW5V4vsQRzV8aii11gf5erqRwH36a7+uPcZskqM
	3ekH8Y97wVWTFX3FVHTPx02g8UTI3Q2f6RYnUxNe6keNJG47F9HF/AQnHc6h4rrw
	4Zhjz+xcQ+EtW8OT4H5sD5bBhxI=
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:reply-to:subject:references:to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=zW5yDOOJBXbusMhRATUOZt
	+c8uY=; b=QLD/YvF/+zytWTFudzS4LHWbrBT12kPWHhNvRFen0oWWr0WpuFhgSt
	3As5KszTXPYZJY71o0UM52erowbisjapuHI08IWYK11zZ9DUqWmbpZpflMbY4h6n
	he0KHe/kxf3vZjiJyURbNGiyVB0HRnGA1ts0WfQMIn/+U3IFbN/Do=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:ip*192.168.0.3, Hx-languages-length:2663, H*M:b10c, moss
X-HELO: mailsrv.cs.umass.edu
Reply-To: moss@cs.umass.edu
Subject: Re: Retrieving per-process environment block?
References: <CAOTD34ZFH5E3r3AuDOXctss46e1hoU2f9pwE1mt4L674J2Ak_A@mail.gmail.com> <20161117140012.GA23664@calimero.vinschen.de> <CAOTD34Y9TRq2Qq8Mn2awTf9SCgz0qnbBa-a117pkSEvz9gaHKQ@mail.gmail.com>
To: cygwin@cygwin.com
From: Eliot Moss <moss@cs.umass.edu>
Message-ID: <98eb08bf-5012-fe14-b10c-241b427c4366@cs.umass.edu>
Date: Tue, 29 Nov 2016 09:28:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CAOTD34Y9TRq2Qq8Mn2awTf9SCgz0qnbBa-a117pkSEvz9gaHKQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

On 11/29/2016 8:26 AM, Erik Bray wrote:
> On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.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.

Regards -- Eliot Moss

--
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