1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
http://cygwin.com/ml/cygwin/2012-03/msg00375.html I am seeing a very similar bug after upgrading. I see reference to a test patch. I am willing to test the update. How can I get a copy? Greg
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Mon, Mar 12, 2012 at 07:51:03PM -, 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 signature.asc Description: Digital signature
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Mon, Mar 05, 2012 at 09:37:50AM -0700, Eric Blake wrote: On 03/05/2012 07:13 AM, Nellis, Kenneth wrote: From: Corinna Vinschen Thanks for the review. Like this? If you're open to improvements, the form x=$(($x + 1)) could arguably be improved with any of the following: x=$((x + 1)) Still POSIX, and supported by /bin/sh (even where /bin/sh is dash) Duly noted. Will be included in next release. Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
RE: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
From: Corinna Vinschen Thanks for the review. Like this? If you're open to improvements, the form x=$(($x + 1)) could arguably be improved with any of the following: x=$((x + 1)) let x=x+1 ((x=x+1)) ((x++)) ((++x)) --Ken Nellis
Re: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Mar 5 08:13, Nellis, Kenneth wrote: From: Corinna Vinschen Thanks for the review. Like this? If you're open to improvements, the form x=$(($x + 1)) could arguably be improved with any of the following: x=$((x + 1)) let x=x+1 ((x=x+1)) ((x++)) ((++x)) It's David's call now. 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: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On 03/05/2012 07:13 AM, Nellis, Kenneth wrote: From: Corinna Vinschen Thanks for the review. Like this? If you're open to improvements, the form x=$(($x + 1)) could arguably be improved with any of the following: x=$((x + 1)) Still POSIX, and supported by /bin/sh (even where /bin/sh is dash) let x=x+1 ((x=x+1)) ((x++)) ((++x)) all bash extensions, so requires /bin/bash. Also, be careful of ((x++)) - if x starts life 0, then that sets $? to 1. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Mar 1 11:08, Corinna Vinschen wrote:
# Fix a problem introduced by older versions of setup.exe
[...]
David, ping? Can we add the below two files to base-files asap and
remove the tmp/temp workaround, please?
/etc/profile.d/1777fix.csh:
#!/bin/tcsh
# Fix a problem introduced by older versions of setup.exe
# Read comments in /etc/profile.d/1777fix.sh for more information.
set GUARDFILE = /etc/.1777fix
if ( ! -f ${GUARDFILE} ) then
/bin/bash /etc/profile.d/1777fix.sh
endif
/etc/profile.d/1777fix.sh:
#!/bin/bash
# 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.
GUARDFILE=/etc/.1777fix
DIRLIST=/home /tmp /usr/tmp /var/log /var/run
if [ ! -f ${GUARDFILE} ]
then
cnt=0
success=0
for file in ${DIRLIST}
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
if getfacl ${file} | grep -Eq 'default:(group:|other):rwx'
then
cnt=$(expr $cnt + 1)
setfacl -m d:g::r-x,d:o:r-x ${file} 2/dev/null \
success=$(expr $success + 1)
fi
done
# If no file needed treatment, or if all setfacl calls succeeded,
# create the
[ $cnt -eq $success ] touch ${GUARDFILE}
fi
Thanks,
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: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On 03/02/2012 03:46 AM, Corinna Vinschen wrote:
On Mar 1 11:08, Corinna Vinschen wrote:
# Fix a problem introduced by older versions of setup.exe
[...]
David, ping? Can we add the below two files to base-files asap and
remove the tmp/temp workaround, please?
/etc/profile.d/1777fix.csh:
#!/bin/tcsh
# Fix a problem introduced by older versions of setup.exe
# Read comments in /etc/profile.d/1777fix.sh for more information.
set GUARDFILE = /etc/.1777fix
if ( ! -f ${GUARDFILE} ) then
/bin/bash /etc/profile.d/1777fix.sh
endif
/etc/profile.d/1777fix.sh:
#!/bin/bash
As long as we're requiring bash,...
# 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.
GUARDFILE=/etc/.1777fix
DIRLIST=/home /tmp /usr/tmp /var/log /var/run
if [ ! -f ${GUARDFILE} ]
then
cnt=0
success=0
for file in ${DIRLIST}
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
if getfacl ${file} | grep -Eq 'default:(group:|other):rwx'
Is it worth converting this to case/esac for one fewer child process?
then
cnt=$(expr $cnt + 1)
...this should be written cnt=$((cnt + 1))
setfacl -m d:g::r-x,d:o:r-x ${file} 2/dev/null \
success=$(expr $success + 1)
and this as success=$((success + 1))
fi
done
# If no file needed treatment, or if all setfacl calls succeeded,
# create the
Incomplete comment.
[ $cnt -eq $success ] touch ${GUARDFILE}
fi
Thanks,
Corinna
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Mar 2 04:59, Eric Blake wrote:
On 03/02/2012 03:46 AM, Corinna Vinschen wrote:
/etc/profile.d/1777fix.sh:
#!/bin/bash
As long as we're requiring bash,...
[...]
if getfacl ${file} | grep -Eq 'default:(group:|other):rwx'
Is it worth converting this to case/esac for one fewer child process?
then
cnt=$(expr $cnt + 1)
...this should be written cnt=$((cnt + 1))
setfacl -m d:g::r-x,d:o:r-x ${file} 2/dev/null \
success=$(expr $success + 1)
and this as success=$((success + 1))
fi
done
# If no file needed treatment, or if all setfacl calls succeeded,
# create the
Incomplete comment.
[ $cnt -eq $success ] touch ${GUARDFILE}
fi
Thanks for the review. Like this?
#!/bin/bash
# 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.
GUARDFILE=/etc/.1777fix
DIRLIST=/home /tmp /usr/tmp /var/log /var/run
if [ ! -f ${GUARDFILE} ]
then
cnt=0
success=0
for file in ${DIRLIST}
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
case $(getfacl ${file}) in
*default:group::rwx* | *default:other:rwx* )
cnt=$(($cnt + 1))
setfacl -m d:g::r-x,d:o:r-x ${file} 2/dev/null \
success=$(($success + 1))
;;
esac
done
# If no file needed treatment, or if all setfacl calls succeeded,
# create the guard file.
[ $cnt -eq $success ] touch ${GUARDFILE}
fi
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: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On 03/02/2012 05:41 AM, Corinna Vinschen wrote: On Mar 2 04:59, Eric Blake wrote: On 03/02/2012 03:46 AM, Corinna Vinschen wrote: /etc/profile.d/1777fix.sh: #!/bin/bash As long as we're requiring bash,... [...] Thanks for the review. Like this? Yes, looks better now. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: base-files: New files to fix permission issues (was Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.)
On Fri, Mar 02, 2012 at 11:46:05AM +0100, Corinna Vinschen wrote: On Mar 1 11:08, Corinna Vinschen wrote: # Fix a problem introduced by older versions of setup.exe [...] David, ping? Can we add the below two files to base-files asap and remove the tmp/temp workaround, please? I'll send an RFU later today. Many thanks for your work. So sorry for the absence, huge pile of RL(TM) stuff these days :( -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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.
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.
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.
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.
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.
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.
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 (anrdae...@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.
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.
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.
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
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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.
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.
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.
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 signature.asc Description: Digital signature
Re: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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.
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 (anrdae...@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
1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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
1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
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
