1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Andres Martinelli]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Cygwin,

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits).

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5.

How to reproduce:

1) Compile the example with
         csc bug.cs

     The c# compiler (csc), can be usually found in
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception.

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions.

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0.

Best regards,
Andrés Martinelli


[-- Attachment #2: bug.cs --]
[-- Type: text/plain, Size: 447 bytes --]

using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;

class Program {
  static void Main(string[] args) {
    XmlSerializer serializer = new XmlSerializer(typeof(Simple));
  }
}

public class Simple : IXmlSerializable {
  #region IXmlSerializable Members
  public XmlSchema GetSchema() { return null; }
  public void ReadXml(XmlReader reader) { }
  public void WriteXml(XmlWriter writer) { }
  #endregion
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 27 16:23, Andres Martinelli wrote:
> Hi Cygwin,
> 
> Many .Net programs that use to run correctly from a cygwin 1.7.9
> console started throwing exceptions after updating to versions
> 1.7.10/1.7.11. I have noticed this problem on machines running
> Windows XP and Vista (32bits).
> 
> I attach a very small example that triggers the bug. The example is
> written in C#, and requires the .Net framework versions 2.0 or 3.5.
> 
> How to reproduce:
> 
> 1) Compile the example with
>         csc bug.cs
> 
>     The c# compiler (csc), can be usually found in
>         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
>     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
> 
> 2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It
> throws an exception.
> 
> 3) Run bug.exe from a native windows console (or a cygwin 1.7.9
> console). It runs without producing any output, and without throwing
> any exceptions.
> 
> Be aware that the bug is not triggered if the example is compiled
> with the .Net framework 4.0.

The problem is that I have not the faintest insight into .Net.  This is
an application written in a language I don't know, using a class library
I don't know, using a compiler I don't know.  And the executable isn't
even a Cygwin application so it doesn't call Cygwin functions.  So I
have no idea what problem this application has.  What on earth is it
trying to tell me?

  Unhandled Exception: System.ArgumentException: Item has already been added. Key
  in dictionary: 'tmp'  Key being added: 'tmp'
     at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
     at System.Collections.Hashtable.Add(Object key, Object value)
     at System.Collections.Specialized.StringDictionary.Add(String key, String value)
     [etc.]


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Jon Clugston]

On Tue, Feb 28, 2012 at 7:56 AM, Corinna Vinschen wrote:


> The problem is that I have not the faintest insight into .Net.  This is
> an application written in a language I don't know, using a class library
> I don't know, using a compiler I don't know.  And the executable isn't
> even a Cygwin application so it doesn't call Cygwin functions.  So I
> have no idea what problem this application has.  What on earth is it
> trying to tell me?
>
>  Unhandled Exception: System.ArgumentException: Item has already been added. Key
>  in dictionary: 'tmp'  Key being added: 'tmp'
>     at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
>     at System.Collections.Hashtable.Add(Object key, Object value)
>     at System.Collections.Specialized.StringDictionary.Add(String key, String value)
>     [etc.]
>

Just a guess, but it does look suspiciously like the name of an
environment variable.  Wasn't there some discussion lately about
differing case environment variables ("tmp" as opposed to "TMP")?

Jon

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 28 08:51, Jon Clugston wrote:
> On Tue, Feb 28, 2012 at 7:56 AM, Corinna Vinschen wrote:
> 
> 
> > The problem is that I have not the faintest insight into .Net.  This is
> > an application written in a language I don't know, using a class library
> > I don't know, using a compiler I don't know.  And the executable isn't
> > even a Cygwin application so it doesn't call Cygwin functions.  So I
> > have no idea what problem this application has.  What on earth is it
> > trying to tell me?
> >
> >  Unhandled Exception: System.ArgumentException: Item has already been added. Key
> >  in dictionary: 'tmp'  Key being added: 'tmp'
> >     at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
> >     at System.Collections.Hashtable.Add(Object key, Object value)
> >     at System.Collections.Specialized.StringDictionary.Add(String key, String value)
> >     [etc.]
> >
> 
> Just a guess, but it does look suspiciously like the name of an
> environment variable.  Wasn't there some discussion lately about
> differing case environment variables ("tmp" as opposed to "TMP")?

Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
in a double definition of the %TMP% and %TEMP% dos variables from the
.Net applications POV and it's too dumb to handle that gracefully.

So the solution is, either we drop the tmp and temp definitions in
/etc/profile, or old .net apps should be started only after calling
`unset tmp temp' in bash.

Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
So I'm wondering why we do it in /etc/profile.  Can somebody give me a
management summary?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[David Sastre Medina]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Tue, Feb 28, 2012 at 03:17:54PM +0100, Corinna Vinschen wrote:
> On Feb 28 08:51, Jon Clugston wrote:
> > Just a guess, but it does look suspiciously like the name of an
> > environment variable.  Wasn't there some discussion lately about
> > differing case environment variables ("tmp" as opposed to "TMP")?
> 
> Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
> in a double definition of the %TMP% and %TEMP% dos variables from the
> .Net applications POV and it's too dumb to handle that gracefully.
> 
> So the solution is, either we drop the tmp and temp definitions in
> /etc/profile, or old .net apps should be started only after calling
> `unset tmp temp' in bash.
> 
> Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
> So I'm wondering why we do it in /etc/profile.  Can somebody give me a
> management summary?

A while back (about the 3.x -> 4.x changes in base-files), it was
agreed to unset both TMP and TEMP and set them to /tmp.
A user concerned about the security of files owned by windows native 
applications started within cygwin, reported that those files were
created with 777 perms under /tmp, making it trivial for other users to
read/copy temps files easily.
The solution proposed, which I included in 4.0-7, was to set temporary
dirs as they are now in /etc/profile.

With regards to tcsh, and apart from /etc/profile.d/*.csh, it doesn't
use any startup file in base-files, as you know it has its own set of 

/etc/csh.login
/etc/csh.cshrc

and a couple of files under /etc/profile.d (as of 6.18.00-3).
So it is not easy for me to propagate this to tcsh. Regardless, it's probably 
my fault not having publicised enough that change to give tcsh, and
probably zsh and mksh (both can use /etc/their-own-startup-profile)
mantainers at least the chance to include it or complain.

If this setting is to be dropped, we'll go back to creating unsecure files
in /tmp under the described scenario (unless some other solution is implemented).

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 28 21:39, David Sastre Medina wrote:
> On Tue, Feb 28, 2012 at 03:17:54PM +0100, Corinna Vinschen wrote:
> > On Feb 28 08:51, Jon Clugston wrote:
> > > Just a guess, but it does look suspiciously like the name of an
> > > environment variable.  Wasn't there some discussion lately about
> > > differing case environment variables ("tmp" as opposed to "TMP")?
> > 
> > Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
> > in a double definition of the %TMP% and %TEMP% dos variables from the
> > .Net applications POV and it's too dumb to handle that gracefully.
> > 
> > So the solution is, either we drop the tmp and temp definitions in
> > /etc/profile, or old .net apps should be started only after calling
> > `unset tmp temp' in bash.
> > 
> > Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
> > So I'm wondering why we do it in /etc/profile.  Can somebody give me a
> > management summary?
> 
> A while back (about the 3.x -> 4.x changes in base-files), it was
> agreed to unset both TMP and TEMP and set them to /tmp.
> A user concerned about the security of files owned by windows native 
> applications started within cygwin, reported that those files were
> created with 777 perms under /tmp, making it trivial for other users to
> read/copy temps files easily.

There's something wrong with this picture.

The default permissions of /tmp are 1777 from the POSIX point of view.
The created files have default permissions which depend on the umask.
For native Win32 application, the default permissions depend on the
setting of the inheritable default permissions.  And these are set so
that the files have default perms of 0755: 

  $ getfacl /tmp
  # file: /tmp
  # owner: somebody
  # group: Administrators
  user::rwx
  group::rwx
  mask:rwx
  other:rwx
  default:user::rwx
  default:group::r-x
  default:other:r-x

This should be entirely sufficent.

[...time passes...]

Oh.  I think I see why this happens.  The inheritable default permissions
are NOT set as above, but rather they are set like this:

  # file: /tmp
  # owner: somebody
  # group: Administrators
  user::rwx
  group::rwx
  mask:rwx
  other:rwx
  default:user::rwx
  default:group::rwx
  default:other:rwx

The culprit is setup.exe apparently.  If it sets 1777 permissions, it
uses the same permissions for the inheritable default permissions.  It
should remove the write bits before creating the inheritable default
permissions.  In Cygwin this is controlled by the umask, but setup
doesn't know about a umask.

So, the correct solution is to change setup.exe to create less dangerous
default permissions for the Win32 apps in case of 1777 dirs.  That makes
the tmp/temp stuff in etc/profile unnecessary.

The *big* problem are the already existing /tmp dirs with bad permissions
throughout the Cygwin users.

David, instead of setting tmp/temp, What about adding the following line
to /etc/profile?

  setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2>/dev/null

That sets the list of directories created with 1777 permissions by
setup.exe itself to more sane permissions.  Maybe it could be combined
with a marker file, along these lines:

  if [ ! -f /etc/.177fix ]
  then
    setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2> /dev/null && touch /etc/.177fix
  fi

In the meantime I'll fix setup to create less dangerous default
permissions in the 1777 case.  Sigh, if I only had observed the issue
more closely when it cropped up the first time :(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Andrey Repin]

Greetings, Corinna Vinschen!

> Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
> in a double definition of the %TMP% and %TEMP% dos variables from the
> .Net applications POV and it's too dumb to handle that gracefully.

> So the solution is, either we drop the tmp and temp definitions in
> /etc/profile, or old .net apps should be started only after calling
> `unset tmp temp' in bash.

> Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
> So I'm wondering why we do it in /etc/profile.  Can somebody give me a
> management summary?

I guess that was an attempt to fix something that isn't made things right, but
left there for years.
I would rather propose to solve it the other way around and use /etc/fstab
functionality to mount Cygwin's /tmp to current user's %TEMP% folder.
I don't know, how would that work in multi-user environment, though.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 29.02.2012, <02:46>

Sorry for my terrible english...


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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 28 22:41, Corinna Vinschen wrote:
> The culprit is setup.exe apparently.  If it sets 1777 permissions, it
> uses the same permissions for the inheritable default permissions.  It
> should remove the write bits before creating the inheritable default
> permissions.  In Cygwin this is controlled by the umask, but setup
> doesn't know about a umask.
> 
> So, the correct solution is to change setup.exe to create less dangerous
> default permissions for the Win32 apps in case of 1777 dirs.  That makes
> the tmp/temp stuff in etc/profile unnecessary.

I just applied a fix to setup so that the default permissions for dirs
created with the sticky bit (t) set don't contain write permissions for
group and other.  I see to it that it will be uploaded to cygwin.com
shortly.

> The *big* problem are the already existing /tmp dirs with bad permissions
> throughout the Cygwin users.
> 
> David, instead of setting tmp/temp, What about adding the following line
> to /etc/profile?
> 
>   setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2>/dev/null
> 
> That sets the list of directories created with 1777 permissions by
> setup.exe itself to more sane permissions.  Maybe it could be combined
> with a marker file, along these lines:
> 
>   if [ ! -f /etc/.177fix ]
>   then
>     setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2> /dev/null && touch /etc/.177fix
>   fi

That should have been /etc/.1777fix, of course.  I think something like
this is necessary since it makes sure that setfacl is called once by a
user with the right permissions and then it's just ignored ever after.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 29 02:51, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
> > in a double definition of the %TMP% and %TEMP% dos variables from the
> > .Net applications POV and it's too dumb to handle that gracefully.
> 
> > So the solution is, either we drop the tmp and temp definitions in
> > /etc/profile, or old .net apps should be started only after calling
> > `unset tmp temp' in bash.
> 
> > Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
> > So I'm wondering why we do it in /etc/profile.  Can somebody give me a
> > management summary?
> 
> I guess that was an attempt to fix something that isn't made things right, but
> left there for years.
> I would rather propose to solve it the other way around and use /etc/fstab
> functionality to mount Cygwin's /tmp to current user's %TEMP% folder.
> I don't know, how would that work in multi-user environment, though.

POSIX tools usually expect that system paths are shared between
processes.  Consider client-server situations with shared files
(sockets, fifos) in /tmp.  So, no, this is not a generic solution
for Cygwin tools.  Any user or admin is free to do that locally,
of course.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Dead on, thanks!  The definitions of tmp and temp in /etc/profile result
>> > in a double definition of the %TMP% and %TEMP% dos variables from the
>> > .Net applications POV and it's too dumb to handle that gracefully.
>> 
>> > So the solution is, either we drop the tmp and temp definitions in
>> > /etc/profile, or old .net apps should be started only after calling
>> > `unset tmp temp' in bash.
>> 
>> > Btw., tmp and temp are not preserved this way in tcsh's profile scripts.
>> > So I'm wondering why we do it in /etc/profile.  Can somebody give me a
>> > management summary?
>> 
>> I guess that was an attempt to fix something that isn't made things right, but
>> left there for years.
>> I would rather propose to solve it the other way around and use /etc/fstab
>> functionality to mount Cygwin's /tmp to current user's %TEMP% folder.
>> I don't know, how would that work in multi-user environment, though.

> POSIX tools usually expect that system paths are shared between
> processes.  Consider client-server situations with shared files
> (sockets, fifos) in /tmp.  So, no, this is not a generic solution
> for Cygwin tools.  Any user or admin is free to do that locally,
> of course.

%SystemRoot%/Temp then ?


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 29.02.2012, <16:21>

Sorry for my terrible english...


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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Earnie Boyd]

On Wed, Feb 29, 2012 at 7:22 AM, Andrey Repin wrote:
>
> %SystemRoot%/Temp then ?
>

This isn't guaranteed to exist.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 29 07:39, Earnie Boyd wrote:
> On Wed, Feb 29, 2012 at 7:22 AM, Andrey Repin wrote:
> >
> > %SystemRoot%/Temp then ?
> >
> 
> This isn't guaranteed to exist.

And it wouldn't change anything.  It all depends on a safe ACL setting
one way or the other.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[David Sastre Medina]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Mon, Mar 12, 2012 at 07:51:03PM -0000, James Johnston wrote:
> I have also noticed this issue; again it was with the XML serialization functions like Andres Martinelli originally noted.  The root of the problem is that Windows environment variables are not case sensitive, while they *are* in a Unix environment.  Cygwin passes an environment block with duplicate identically-named variables (if case insensitive; unique if case sensitive), and this will make some Windows programs go boom, because they assume the block is maintained in a case-insensitive manner.
> The big problem as I see it is that Cygwin, out-of-the-box, creates an environment block that violates a basic assumption of Windows programs - that the environment block is not case sensitive.  I don't know what the solution should be, but it's not this.
> 
> From /etc/profile:
> 
> tmp=$(cygpath -w "$ORIGINAL_TMP" 2> /dev/null)
> temp=$(cygpath -w "$ORIGINAL_TEMP" 2> /dev/null)
> TMP="/tmp"
> TEMP="/tmp"
> 
> This code is what causes the crash, by creating these "duplicate" (from a Windows perspective) keys.
> 
> I would guess that any Windows program that tries to do case-insensitive lookups in the environment is liable to crash.  At the very least, it won't necessarily give you the answer you expect (if both "TEMP" and "temp" store different values and you do a case insensitive lookup of "TeMp", which is going to be returned if you don't crash?)

There is a test release for base-files addressing this issue. Could
you try if that solves this problem for you?

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[James Johnston]

I have also noticed this issue; again it was with the XML serialization functions like Andres Martinelli originally noted.  The root of the problem is that Windows environment variables are not case sensitive, while they *are* in a Unix environment.  Cygwin passes an environment block with duplicate identically-named variables (if case insensitive; unique if case sensitive), and this will make some Windows programs go boom, because they assume the block is maintained in a case-insensitive manner.

Here's a full stack trace:

Unhandled Exception: System.ArgumentException: Item has already been added. Key in dictionary: 'tmp'  Key being added: 'tmp'
   <cut>
   at System.Collections.Specialized.StringDictionary.Add(String key, String value)
   at System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated(SafeUserTokenHandle userToken, String cmd, String currentDir, TempFileCollection tempFiles, String& outputName, String& errorName, String trueCmdLine)
   <cut>
   at Microsoft.CSharp.CSharpCodeGenerator.Compile(CompilerParameters options, String compilerDirectory, String compilerExe, String arguments, String& outputFile, Int32& nativeReturnValue, String trueArgs)
   <cut>
   at System.Xml.Serialization.XmlSerializer..ctor(Type type)

You can see that the XML serializer needs to invoke the C# compiler to dynamically compile some code.  The compiler needs to place all environment variables in a case-insensitive dictionary (since that's how things are done on Windows!).  Decompiling System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated gives this:

        StringDictionary sd = new StringDictionary();
        foreach (DictionaryEntry entry in Environment.GetEnvironmentVariables())
        {
            sd.Add((string) entry.Key, (string) entry.Value);
        }

Note that StringDictionary is case insensitive, according to the docs: "The key is handled in a case-insensitive manner; it is translated to lowercase before it is used with the string dictionary."  So that's why it crashes.

The big problem as I see it is that Cygwin, out-of-the-box, creates an environment block that violates a basic assumption of Windows programs - that the environment block is not case sensitive.  I don't know what the solution should be, but it's not this.

From /etc/profile:

tmp=$(cygpath -w "$ORIGINAL_TMP" 2> /dev/null)
temp=$(cygpath -w "$ORIGINAL_TEMP" 2> /dev/null)
TMP="/tmp"
TEMP="/tmp"

This code is what causes the crash, by creating these "duplicate" (from a Windows perspective) keys.

I would guess that any Windows program that tries to do case-insensitive lookups in the environment is liable to crash.  At the very least, it won't necessarily give you the answer you expect (if both "TEMP" and "temp" store different values and you do a case insensitive lookup of "TeMp", which is going to be returned if you don't crash?)

James

--- Original message ---

Hi Cygwin, 

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits). 

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5. 

How to reproduce: 

1) Compile the example with 
         csc bug.cs 

     The c# compiler (csc), can be usually found in 
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe 
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe 

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception. 

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions. 

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0. 

Best regards, 
Andrés Martinelli 


using System.Xml; 
using System.Xml.Schema; 
using System.Xml.Serialization; 

class Program { 
  static void Main(string[] args) { 
    XmlSerializer serializer = new XmlSerializer(typeof(Simple)); 
  } 
} 

public class Simple : IXmlSerializable { 
  #region IXmlSerializable Members 
  public XmlSchema GetSchema() { return null; } 
  public void ReadXml(XmlReader reader) { } 
  public void WriteXml(XmlWriter writer) { } 
  #endregion 
}


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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Matt Seitz (matseitz)]

"Corinna Vinschen" wrote news:
> On Mar  1 10:16, Matt Seitz (matseitz) wrote:
> > 
> > Here's another thought:  is the problem only with the "/home"
directory
> > that Cygwin setup creates (ex: /cygdrive/c/cygwin/home)?  If so,
would
> > it be possible to only modify that original "/home" directory, and
not
> > whatever directory "/home" might now point to?
> 
> If you have the inheritable default permissions set as the getfacl
> tests, then you should be glad if this gets changed, regardless
whether
> this is the same /home that setup created.

OK, fair enough.  I just thought it might be safer or "more polite" for
Setup to not change permissions which Setup didn't set in the first
place, or that the user might have explicitly set.  And, of course, the
user always has the option to change the permissions back again if they
really want them.


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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Mar  1 10:16, Matt Seitz (matseitz) wrote:
> "Corinna Vinschen" wrote:
> > 
> > Maybe it's better if the code tests the permissions first, along these
> > lines:
> 
> Thanks.  I would feel better with a solution that doesn't change my
> permissions if they don't really need to be changed.
> 
> Here's another thought:  is the problem only with the "/home" directory
> that Cygwin setup creates (ex: /cygdrive/c/cygwin/home)?  If so, would
> it be possible to only modify that original "/home" directory, and not
> whatever directory "/home" might now point to?

If you have the inheritable default permissions set as the getfacl
tests, then you should be glad if this gets changed, regardless whether
this is the same /home that setup created.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Matt Seitz (matseitz)]

"Corinna Vinschen" wrote:
> 
> Maybe it's better if the code tests the permissions first, along these
> lines:

Thanks.  I would feel better with a solution that doesn't change my
permissions if they don't really need to be changed.

Here's another thought:  is the problem only with the "/home" directory
that Cygwin setup creates (ex: /cygdrive/c/cygwin/home)?  If so, would
it be possible to only modify that original "/home" directory, and not
whatever directory "/home" might now point to?



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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Corinna Vinschen]

On Feb 29 13:36, Matt Seitz (matseitz) wrote:
> "Corinna Vinschen" wrote:
> >   setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run
> /var/tmp 2>/dev/null
> 
> Will that cause problems if I have:
> 
> $ mount | grep home
> C:/Documents and Settings on /home type ntfs (binary)
> $ getfacl /home
> # file: /home
> # owner: Administrators
> # group: Domain Users
> user::rwx
> group::---
> group:SYSTEM:rwx
> group:Users:r-x
> group:Power Users:r-x
> mask:rwx
> other:r-x
> default:user::rwx
> default:user:Administrators:rwx
> default:group::---
> default:group:SYSTEM:rwx
> default:group:Users:r-x
> default:group:Power Users:r-x
> default:mask:rwx
> default:other:r-x
> $

I don't know if that's a problem for you, but it would change the
settings to

  $ getfacl /home
  [...]
  default:group::r-x                 <---
  [...]
  $

Maybe it's better if the code tests the permissions first, along these
lines:

  # Fix a problem introduced by older versions of setup.exe
  # Directories with 1777 permissions were erroneously created
  # with 777 inheritable default permissions.  This is a security
  # problem for non-Cygwin apps using these folders.  This is
  # especially tragic in case of /tmp.
  if [ ! -f /etc/.1777fix ]
  then
    for file in /home /tmp /usr/tmp /var/log /var/run
    do
      # We test if the default group or other permissions are rwx.
      # If so, it's dangerous and highly likely that these are still
      # the permissions set by setup.exe
      getfacl "${file}" | grep -Eq 'default:(group:|other):rwx' \
      && setfacl -m d:g::r-x,d:o:r-x "${file}" 2>/dev/null \
      && touch /etc/.1777fix
    done
  fi

That should be sufficiently safe.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Matt Seitz (matseitz)]

"Corinna Vinschen" wrote:
> 
> David, instead of setting tmp/temp, What about adding the following
line
> to /etc/profile?
> 
>   setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run
/var/tmp 2>/dev/null

Will that cause problems if I have:

$ mount | grep home
C:/Documents and Settings on /home type ntfs (binary)
$ getfacl /home
# file: /home
# owner: Administrators
# group: Domain Users
user::rwx
group::---
group:SYSTEM:rwx
group:Users:r-x
group:Power Users:r-x
mask:rwx
other:r-x
default:user::rwx
default:user:Administrators:rwx
default:group::---
default:group:SYSTEM:rwx
default:group:Users:r-x
default:group:Power Users:r-x
default:mask:rwx
default:other:r-x
$


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

1.7.10/1.7.11: .Net programs started from a cygwin console may fail.

[Andres Martinelli]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Cygwin,

Many .Net programs that use to run correctly from a cygwin 1.7.9 console 
started throwing exceptions after updating to versions 1.7.10/1.7.11. I 
have noticed this problem on machines running Windows XP and Vista (32bits).

I attach a very small example that triggers the bug. The example is 
written in C#, and requires the .Net framework versions 2.0 or 3.5.

How to reproduce:

1) Compile the example with
         csc bug.cs

     The c# compiler (csc), can be usually found in
         C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
     or C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe

2) Run the resulting bug.exe from a cygwin 1.7.10/1.7.11 console. It 
throws an exception.

3) Run bug.exe from a native windows console (or a cygwin 1.7.9 
console). It runs without producing any output, and without throwing any 
exceptions.

Be aware that the bug is not triggered if the example is compiled with 
the .Net framework 4.0.

Best regards,
Andrés Martinelli


[-- Attachment #2: bug.cs --]
[-- Type: text/plain, Size: 447 bytes --]

using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;

class Program {
  static void Main(string[] args) {
    XmlSerializer serializer = new XmlSerializer(typeof(Simple));
  }
}

public class Simple : IXmlSerializable {
  #region IXmlSerializable Members
  public XmlSchema GetSchema() { return null; }
  public void ReadXml(XmlReader reader) { }
  public void WriteXml(XmlWriter writer) { }
  #endregion
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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