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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=B8VynBnOyfUaRNbWHz/6WmEf+HdswRsHGg4BJvj9PyTVP1btiRfBm
	4d0/36DnX1kpBVU/3AsXlOM4EMk6MO98K993IPSk+CdUnTOfZgoxqi7bngmG5vhK
	N0McWIKG9+DZTStE5eZEN6gH9h+ngrjgyr9gPO26xEd1QMgy2eC1iU=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=E/+7PUhcYmHJiaQfFrSFWtb3gDU=; b=MpdfVrfJU4rBcyx0ZF1RmTn/x4Qv
	7DFxMY+0lrP7Aak9UKCjSZJhiczmA+1P0C6+/CbADQVE1HwqKc3NsqBUSgxWcJXK
	rTmNF2HVgiSQnRH07dRzgzcNkD1uiGm32zp+XKKZyXNCaiDkg6GugRC5DcVt+EAB
	wTCYzNQuZJoEr7Q=
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=-101.6 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=consent, H*R:D*cygwin.com, replying, H*R:U*cygwin
X-HELO:	drew.franken.de
Date:	Wed, 30 Nov 2016 11:43:34 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Retrieving per-process environment block?
Message-ID:	<20161130104334.GB14074@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
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>
MIME-Version:	1.0
In-Reply-To:	<CAOTD34Y9TRq2Qq8Mn2awTf9SCgz0qnbBa-a117pkSEvz9gaHKQ@mail.gmail.com>
User-Agent:	Mutt/1.7.1 (2016-10-04)

--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Erik,

On Nov 29 14:26, 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 ;)
>=20
> 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.
>=20
> 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.

You're right, it's not *that* straightforward.  I got carried away by
the idea but didn't think this through when replying to you.

So, how to implement this?

We have two types of information in /proc/$PID, one is information
readily available without having to contact the target process, the
other information is local to the target process and we have to get the
information with the target processes consent.  Argc, argv pointers
are in the second group.

So how do we contact the other process to ask for information?

We have a mechanism inside Cygwin to request info from another process.
It's part of the signal handling and consists basically of two
functions.  The applicant calls _pinfo::commune_request(), this will
send a request into the signal pipe of the target process, this in turn
will call commune_process(), a callback function, within the target
process.

Have a look into an example:

Start in fhandler_process.cc, function format_process_cmdline()
which implements /proc/$PID/cmdline.

It fetches the _pinfo pointer of the target process and calls
_pinfo::cmdline.

_pinfo::cmdline (in pinfo.cc) checks if the target process is a
native Windows process a Cygwin process, or if its itself.

In the native Windows case, it opens a handle to the target process,
fetches its RTL_USER_PROCESS_PARAMETERS block (function
open_commune_proc_parms).  and fetches the info from the target process
by directly reading from its memory.  If it's itself it just constructs
the info as desired and returns.  Boring.

In the Cygwin case, it calls _pinfo::commune_request (PICOM_CMDLINE).
PICOM_CMDLINE is defined in pinfo.h, together with other values for the
commune requests.  It send the request over the signal pipe to the
target process.

The target process receives the request and calls commune_process().  It
checks what info is requested, prepares the info and send it back over
over the signal pipe.

The (waiting) _pinfo::commune_request fetches the info from the pipe and
returns to _pinfo::cmdline, which in turn returns to format_process_cmdline=
().

So, ultimately, just copy the functionality of format_process_cmdline,
_pinfo::cmdline, as well as the handling of PICOM_CMDLINE in
_pinfo::commune_request and commune_process and you're done.


Does that help?


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYPq1WAAoJEPU2Bp2uRE+gT0AP/2R6IVfbXIi4c3kGWicWikHV
zPpavz9MJYOPMUPRkjrOXSd2WSGKk5pPkfB4ZQGkXu2srTNjE+IH4FiaA3jwCWp2
zsxweN4nmM43BmwMkd2/xnsHZaCjniR2i+g6rodVurx/xsCDa5NlvtH/6+4l2Bix
ID4obbgwWk/Q3NC7AYHSdUBpVoAeDMVCusRBeo3q8AI2Xg5FyJkhb6Ka/sVYnykM
f/EiLrBfLrXqPa5iNXMEns0FTO7H/Y/G0afOUQRFKREuXOtDSqkKdUBrg7iMHLrS
pOFdH+4vNEKCSt6iH7oZxYBuUZH31qRbnyqsTF4RlNOi6/+MXyse2k9S4W7lQsjC
2ALcmbimJs5RGAIS6jLQaBFP+gEMbpsbevBYGGjz5aplCYXBxyr0G0un6n7ja5iH
tdhGqW8oiUSb5502PZKqpQt/0Ys3sBA9B9CeVJQOVJoZrxEKxxufv9FpMj5a6d9O
oGyR+8jiS6JF0C36RuDMQAwpzAVicWq/cSuZ4pXwgammElSVxMVmRkMs3yM/9Bkn
MXXfWnUiVljfsAzrA28CbniOX/rlUSkQPTfmD6m0ZvXirXRYC/yVoh7OpK4sZLHW
Bz/O9G552sRnyYjmPkrGTaYCY4tx0JFodqSTqCdh8SZPYOPRBUBkmy/EDJksYA6m
3eZDv5fa/kD5wCVSINnC
=UIwQ
-----END PGP SIGNATURE-----

--k+w/mQv8wyuph6w0--

- Raw text -