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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=oUTep0xz8g2uy7pt7iOB+N75/1NZrg17keWIgTAMmay9n48FnrcpE
	Wh03oRc/FdSk2mcB24LBPV/8fLf3/kogHpTFYuwG2bG4yfKTkxZti8FLwIA+ZxqI
	N1UWWwxGTvHqzklF7i6g5pP5fg1V+kBYtUoS1OYL2kvt3pGM/xnB6A=
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=OH0GOcJyg4UErjDVfHz7SVdAN70=; b=H9KDkLQSONPAGm7P71hinLvWa1gJ
	yr41cIfWlvd+QOJeGG6wo8/rHK+VAppsj79e0o/8RLAyDcQ/qr4wOWgxzqsHT7Cd
	QB2aL1oJp9nL1vd08CWkIvkDdWOH9FOgplFdiJTH+bFgM+mAdnrplFkCILXDmmAr
	g0pwK5sBYNDNvNI=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 14 Jan 2015 12:36:46 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Message-ID: <20150114113646.GB15791@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <8761cez7qi.fsf@Rainer.invalid> <20150112103834.GA15213@calimero.vinschen.de> <loom.20150113T124708-54@post.gmane.org> <20150113125648.GV15791@calimero.vinschen.de> <loom.20150113T135909-484@post.gmane.org> <20150113135339.GW15791@calimero.vinschen.de> <loom.20150113T150342-521@post.gmane.org> <04ae01d02f3e$7eb2f6c0$7c18e440$@gmail.com> <20150113154719.GX15791@calimero.vinschen.de> <074901d02f64$e54a6f00$afdf4d00$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="oJFDFiWc3BlD0xT/"
Content-Disposition: inline
In-Reply-To: <074901d02f64$e54a6f00$afdf4d00$@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

--oJFDFiWc3BlD0xT/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 13 14:12, cyg Simple wrote:
> > From: Corinna Vinschen
> > On Jan 13 09:37, cyg Simple wrote:
> > user's Windows default environment at the time of a user context switch=
 (for
> > instance, logon via ssh).  In that case, "leaving it as is"
> > today would mean to *drop* TMP/TEMP from the environment, because that's
> > what ssh does anyway.  Ssh drops almost everything from the environment,
> > before exec'ing the child process.  And that's a good thing, because the
> > environment (e.g. LOCALAPPDATA, USERPROFILE, etc) would otherwise refle=
ct
> > the settings of the user running the sshd service, not the settings of =
the user just
> > logging in.
> >=20
>=20
> Shouldn't these be removed during the startup of sshd?  Then the child
> process would setup the variables during the login process?

That's basically what happens, except that sshd only removes the
variables when starting the child process, not at its own process
startup.

> > Having said that, TMP/TEMP have the downside of being used by POSIX and
> > Windows applications alike.  Therefore these variables usually are conv=
erted
> > from Windows to POSIX and vice versa on the fly.
>=20
> This is what I was referring to earlier.

Yup, I just reiterated it to make sure the procedure is clear.

> > However, whether it makes sense to set TMP/TEMP in a ssh logon session =
or a
> > cron session is questionable.
>=20
> Ack.  The environment tends to be empty on cron in *nix so I agree.  The =
logon process tends to be what sets the variables, however with Cygwin sshd=
 we need to logon to a new user; would remote desktop protocol provider API=
 help?
>=20
> http://msdn.microsoft.com/en-us/library/dd919947(v=3Dvs.85).aspx

It has no functions for that afaics.  I'm using CreateEnvironmentBlock
to fetch the user's default Windows env and then merge it into the
environment propagated to the child process running under the user's
account.  I just added code to skip all crucial variables (e.g. TMP,
TEMP, PATH) and uploaded a new snapshot with this change to
https://cygwin.com/snapshots/  I'm also going to release another
test release today.


Corinna

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

--oJFDFiWc3BlD0xT/
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUtlTOAAoJEPU2Bp2uRE+gnu0P/RBZihzTZBhxiuO9kMO/VCBw
f8QSwa4UBO87+O77cIxQy53bgmG1H5nER5JGDcPxMBvf8nfTqT7asAr4HmNRGD/9
pSCSbE9g+o7LiqSPXcipsKa8zzHrm7i2XS0xzOB5WFLCMXsi+9Ho5CKrcY1ueRK8
I78HoAM5fJTX1QxKvjHH1sFfq1Mc90y6VnJNSJtMfGTObuFgC2k5YSFb5CwMo73U
Hg/3zz4MG8+ogDlUMnGg1Uqr+Xu+StK4dKTSMpzxnW1eNHommkKeiojBrrZTkGxY
yBQASPjjM97q2iT68PNGadvMr87n4HywgMeBXhDuKn7uO5HhbtQquQXgLmxma8mG
VTtWPHqTCVYE+vb5oHl9Uud3cCegPlZd9HDMyS+cKLFBPk/vH0km86+avLl8gQNj
NMH1+AizMLprrVy2kU6HI7+ifFFnZIsXMg4/++Bq0wEhZSHKiQ5T8XmYvMGMitX8
fgktyF+R2jU8I3BcNSM7NjW23YIZksBXkAc/VcFe8fDqFzGpc6Pe7EW76QsFYhxA
hmyOgndODGB9RsN/hXDtHua6+Z6Syypkk3Xarjn7lE306zAAOPXBrgaZ5Ys8T0Qc
SjHCWN2518Ikk0ny5pHlsIlb4gBN84U/GHFcm/TjzXMrO5bDLNRpiS7Efk5NUdH6
iA1MmwtTTrWD3bbVID/C
=Qge4
-----END PGP SIGNATURE-----

--oJFDFiWc3BlD0xT/--
