Sean Morgan wrote: > Adding the environment variables to HKEY_LOCAL_MACHINE\SYSTEM > \CurrentControlSet\Services\sshd\Parameters\Environment does not seem to > have an effect outside of the CYGWIN variable which does in fact change > after editing the registry. This provided me with some verification that > I had in fact been carrying out my experimentation on the appropriate > key.
This has nothing to do with privilege separation. It is by design. Please see: <http://www.cygwin.com/ml/cygwin/2006-10/msg00729.html> You can see the list of environment variables that are whitelisted in openbsd-compat/bsd-cygwin_util.c: static struct wenv { const char *name; size_t namelen; } wenv_arr[] = { { NL("ALLUSERSPROFILE=") }, { NL("COMMONPROGRAMFILES=") }, { NL("COMPUTERNAME=") }, { NL("COMSPEC=") }, { NL("CYGWIN=") }, { NL("NUMBER_OF_PROCESSORS=") }, { NL("OS=") }, { NL("PATH=") }, { NL("PATHEXT=") }, { NL("PROCESSOR_ARCHITECTURE=") }, { NL("PROCESSOR_IDENTIFIER=") }, { NL("PROCESSOR_LEVEL=") }, { NL("PROCESSOR_REVISION=") }, { NL("PROGRAMFILES=") }, { NL("SYSTEMDRIVE=") }, { NL("SYSTEMROOT=") }, { NL("TMP=") }, { NL("TEMP=") }, { NL("WINDIR=") } }; Those are the only environment variables that will be propagated into the newly created session. The proper way to handle this is to set them in an /etc/profile-type file, as you would on a unix/linux system. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
