From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57584 invoked by alias); 30 Nov 2016 10:43:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 57567 invoked by uid 89); 30 Nov 2016 10:43:50 -0000 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 Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 10:43:40 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id DB5DE72106C27 for ; Wed, 30 Nov 2016 11:43:35 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 681545E0264 for ; Wed, 30 Nov 2016 11:43:34 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 5D1C2A805A1; Wed, 30 Nov 2016 11:43:34 +0100 (CET) Date: Wed, 30 Nov 2016 10:48:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Retrieving per-process environment block? Message-ID: <20161130104334.GB14074@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20161117140012.GA23664@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2016-11/txt/msg00349.txt.bz2 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4588 Hi Erik, On Nov 29 14:26, Erik Bray wrote: > On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen > 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//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//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" Content-length: 819 -----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--