[Mono-list] VFAT vs Unix filesystems...
Piers Haken
piersh@friskit.com
Wed, 8 Jan 2003 16:38:54 -0800
This is a multi-part message in MIME format.
------_=_NextPart_001_01C2B777.7D23BFA2
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
For strongly named assemblies, such as those in the GAC, isn't the
assembly file name part of the hash? If so then this would imply case
sensitivity, and as long as the file names on unix have the right case
then this won't be a problem. Of course, the problem for weakly named
assemblies still exists...
Piers.
> -----Original Message-----
> From: Simon Waite [mailto:simon@psionics.demon.co.uk]=20
> Sent: Wednesday, January 08, 2003 2:46 PM
> To: Mono List
> Subject: Re: [Mono-list] VFAT vs Unix filesystems...
>=20
>=20
> I maintain the premise that dumbing down the DLL search=20
> method is a "Bad Idea"(tm) - depending on which strategy you=20
> use to lookup MyAssembly.dll.
>=20
> For instance a malicious user could insert MYASSEMBLY.DLL into the=20
> search path, and override the assembly the app is taking. -=20
> Possibly with disasterous concequences.
>=20
> Of course the most likely story is that someone will=20
> accidently have this problem, and spend days figuring it out.=20
> Regardless if you do=20
> dumb down the FS in mono ,leaving it as-is presents a similar=20
> problem it has to be written in the documentation in LARGE LETTERS.
>=20
> As for GAC, I'm not even sure any discussion documents wrt unix=20
> implementations are even about. I know for one, that I'd not=20
> want mono being suid and handling all the assemblies for a cache.
>=20
> The most likely case being is something like a .mono/gac=20
> directory for each user, with a /var/share/mono/gac for=20
> system-wide officially sanctioned assemblies - maybe.
>=20
>=20
> Just my 2p
>=20
> -S
>=20
> ----- Original Message -----=20
> From: "Jonathan Pryor" <jonpryor@vt.edu>
> To: "Pablo Baena" <pbaena@uol.com.ar>
> Cc: "Mono List" <mono-list@ximian.com>
> Sent: Wednesday, January 08, 2003 4:14 PM
> Subject: Re: [Mono-list] VFAT vs Unix filesystems...
>=20
>=20
> > My two cents (since everyone else has already given theirs...)
> >=20
> > Mono should be case-insensitive for all assembly name lookups.
> >=20
> > Why? Compatibility. And it makes sense. Here's why.
> >=20
> > Long term (IIRC) we'll be following .NET. Which means=20
> we'll have the=20
> > concept of shared assemblies (located in the Global Assembly Cache
> > (GAC)) and non-shared assemblies, located in the same=20
> directory (or a
> > sub-directory) as the executable.
> >=20
> > The GAC stores an assemblies version, locale, public key,=20
> etc., along=20
> > with the assemblies file name. This allows multiple=20
> different vendors=20
> > to have a shared assembly with the same name (e.g.=20
> > MySharedAssembly.dll) installed at the same time, since the=20
> public key=20
> > *must* be different (different vendors). Likewise for two=20
> different=20
> > versions of a shared assembly from the same vendor: the=20
> version will=20
> > be different, so you'll have to store multiple copies.
> >=20
> > End result: for shared assemblies, you can't just use=20
> case-sensitive=20
> > name comparisons anyway, since you need to take the version, public=20
> > key, etc. into consideration. For shared assemblies,=20
> case-insensitive=20
> > name comparisons are the least of our worries, so we can always use=20
> > case-insensitive searches.
> >=20
> > That leaves local/non-shared assemblies. Since these will=20
> be in the=20
> > application's directory, we could argue that name casing is=20
> > irrelevant, so just use case-sensitive names. However, when would=20
> > case-sensitive names be important for a single executable? =20
> When you=20
> > have ``Assembly.dll'' and ``assembly.dll'' used by the same=20
> program. =20
> > Unless they're in different sub-directories, this likely=20
> won't operate=20
> > properly under .NET since Windows will only see one of those files,=20
> > not both. Plus, it would be brain-dead/stupid for a developer to do=20
> > that, so I don't see much point in supporting that behavior.
> >=20
> > So, *long-term*, I think case-insensitive searches should be the=20
> > default. However, before we get there we need to implement GAC=20
> > support and the rest of the assembly-loading algorithms.
> >=20
> > Short term, stick with the current behavior. We should focus on=20
> > correct long-term behavior instead of worrying about=20
> short-term hacks.
> >=20
> > - Jon
> >=20
> > On Tue, 2003-01-07 at 20:21, Pablo Baena wrote:
> > > I've noticed that when a .NET assembly is referenced on a program=20
> > > running on Windows, the casing of the assembly name is=20
> ignored, thus=20
> > > when running the compiled program on Unix (or any real OS=20
> :O), Mono=20
> > > will fail to load the assembly if only one character=20
> differs on the=20
> > > case.
> > >=20
> > > Am I clear on this? Just to clarify my stupid english:
> > >=20
> > > I have a Classpath.dll on Windows. I compile the program with:
> > >=20
> > > mcs /r:classpath chachacha.cs
> > >=20
> > > which ends successfully.
> > >=20
> > > Then when I run the prog in Linux, mono fails because it doesn't=20
> > > find classpath.dll, and this is solved renaming the dll,=20
> but this is=20
> > > just annoying.
> > >=20
> > > Fill a bug report I should?
> > >=20
> > > --
> > > Pablo Baena <pbaena@uol.com.ar>
> >=20
> >=20
> > _______________________________________________
> > Mono-list maillist - Mono-list@ximian.com=20
> > http://lists.ximian.com/mailman/listinfo/mono-list
>=20
> _______________________________________________
> Mono-list maillist - Mono-list@ximian.com=20
> http://lists.ximian.com/mailman/listinfo/mono-list
>=20
------_=_NextPart_001_01C2B777.7D23BFA2
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [Mono-list] VFAT vs Unix filesystems...</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>For strongly named assemblies, such as those in the =
GAC, isn't the assembly file name part of the hash? If so then this =
would imply case sensitivity, and as long as the file names on unix have =
the right case then this won't be a problem. Of course, the problem for =
weakly named assemblies still exists...</FONT></P>
<P><FONT SIZE=3D2>Piers.</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Simon Waite [<A =
HREF=3D"mailto:simon@psionics.demon.co.uk">mailto:simon@psionics.demon.co=
.uk</A>] </FONT>
<BR><FONT SIZE=3D2>> Sent: Wednesday, January 08, 2003 2:46 PM</FONT>
<BR><FONT SIZE=3D2>> To: Mono List</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Mono-list] VFAT vs Unix =
filesystems...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I maintain the premise that dumbing down the DLL =
search </FONT>
<BR><FONT SIZE=3D2>> method is a "Bad Idea"(tm) - depending =
on which strategy you </FONT>
<BR><FONT SIZE=3D2>> use to lookup MyAssembly.dll.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> For instance a malicious user could insert =
MYASSEMBLY.DLL into the </FONT>
<BR><FONT SIZE=3D2>> search path, and override the assembly the app =
is taking. - </FONT>
<BR><FONT SIZE=3D2>> Possibly with disasterous concequences.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Of course the most likely story is that someone =
will </FONT>
<BR><FONT SIZE=3D2>> accidently have this problem, and spend days =
figuring it out. </FONT>
<BR><FONT SIZE=3D2>> Regardless if you do </FONT>
<BR><FONT SIZE=3D2>> dumb down the FS in mono ,leaving it as-is =
presents a similar </FONT>
<BR><FONT SIZE=3D2>> problem it has to be written in the =
documentation in LARGE LETTERS.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> As for GAC, I'm not even sure any discussion =
documents wrt unix </FONT>
<BR><FONT SIZE=3D2>> implementations are even about. I know for one, =
that I'd not </FONT>
<BR><FONT SIZE=3D2>> want mono being suid and handling all the =
assemblies for a cache.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The most likely case being is something like a =
.mono/gac </FONT>
<BR><FONT SIZE=3D2>> directory for each user, with a =
/var/share/mono/gac for </FONT>
<BR><FONT SIZE=3D2>> system-wide officially sanctioned assemblies - =
maybe.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Just my 2p</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -S</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> ----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>> From: "Jonathan Pryor" =
<jonpryor@vt.edu></FONT>
<BR><FONT SIZE=3D2>> To: "Pablo Baena" =
<pbaena@uol.com.ar></FONT>
<BR><FONT SIZE=3D2>> Cc: "Mono List" =
<mono-list@ximian.com></FONT>
<BR><FONT SIZE=3D2>> Sent: Wednesday, January 08, 2003 4:14 PM</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Mono-list] VFAT vs Unix =
filesystems...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > My two cents (since everyone else has =
already given theirs...)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Mono should be case-insensitive for all =
assembly name lookups.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Why? Compatibility. And it =
makes sense. Here's why.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Long term (IIRC) we'll be following =
.NET. Which means </FONT>
<BR><FONT SIZE=3D2>> we'll have the </FONT>
<BR><FONT SIZE=3D2>> > concept of shared assemblies (located in =
the Global Assembly Cache</FONT>
<BR><FONT SIZE=3D2>> > (GAC)) and non-shared assemblies, located =
in the same </FONT>
<BR><FONT SIZE=3D2>> directory (or a</FONT>
<BR><FONT SIZE=3D2>> > sub-directory) as the executable.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > The GAC stores an assemblies version, =
locale, public key, </FONT>
<BR><FONT SIZE=3D2>> etc., along </FONT>
<BR><FONT SIZE=3D2>> > with the assemblies file name. This =
allows multiple </FONT>
<BR><FONT SIZE=3D2>> different vendors </FONT>
<BR><FONT SIZE=3D2>> > to have a shared assembly with the same =
name (e.g. </FONT>
<BR><FONT SIZE=3D2>> > MySharedAssembly.dll) installed at the same =
time, since the </FONT>
<BR><FONT SIZE=3D2>> public key </FONT>
<BR><FONT SIZE=3D2>> > *must* be different (different =
vendors). Likewise for two </FONT>
<BR><FONT SIZE=3D2>> different </FONT>
<BR><FONT SIZE=3D2>> > versions of a shared assembly from the same =
vendor: the </FONT>
<BR><FONT SIZE=3D2>> version will </FONT>
<BR><FONT SIZE=3D2>> > be different, so you'll have to store =
multiple copies.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > End result: for shared assemblies, you =
can't just use </FONT>
<BR><FONT SIZE=3D2>> case-sensitive </FONT>
<BR><FONT SIZE=3D2>> > name comparisons anyway, since you need to =
take the version, public </FONT>
<BR><FONT SIZE=3D2>> > key, etc. into consideration. For =
shared assemblies, </FONT>
<BR><FONT SIZE=3D2>> case-insensitive </FONT>
<BR><FONT SIZE=3D2>> > name comparisons are the least of our =
worries, so we can always use </FONT>
<BR><FONT SIZE=3D2>> > case-insensitive searches.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > That leaves local/non-shared =
assemblies. Since these will </FONT>
<BR><FONT SIZE=3D2>> be in the </FONT>
<BR><FONT SIZE=3D2>> > application's directory, we could argue =
that name casing is </FONT>
<BR><FONT SIZE=3D2>> > irrelevant, so just use case-sensitive =
names. However, when would </FONT>
<BR><FONT SIZE=3D2>> > case-sensitive names be important for a =
single executable? </FONT>
<BR><FONT SIZE=3D2>> When you </FONT>
<BR><FONT SIZE=3D2>> > have ``Assembly.dll'' and ``assembly.dll'' =
used by the same </FONT>
<BR><FONT SIZE=3D2>> program. </FONT>
<BR><FONT SIZE=3D2>> > Unless they're in different =
sub-directories, this likely </FONT>
<BR><FONT SIZE=3D2>> won't operate </FONT>
<BR><FONT SIZE=3D2>> > properly under .NET since Windows will only =
see one of those files, </FONT>
<BR><FONT SIZE=3D2>> > not both. Plus, it would be =
brain-dead/stupid for a developer to do </FONT>
<BR><FONT SIZE=3D2>> > that, so I don't see much point in =
supporting that behavior.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > So, *long-term*, I think case-insensitive =
searches should be the </FONT>
<BR><FONT SIZE=3D2>> > default. However, before we get there =
we need to implement GAC </FONT>
<BR><FONT SIZE=3D2>> > support and the rest of the =
assembly-loading algorithms.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Short term, stick with the current =
behavior. We should focus on </FONT>
<BR><FONT SIZE=3D2>> > correct long-term behavior instead of =
worrying about </FONT>
<BR><FONT SIZE=3D2>> short-term hacks.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > - Jon</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > On Tue, 2003-01-07 at 20:21, Pablo Baena =
wrote:</FONT>
<BR><FONT SIZE=3D2>> > > I've noticed that when a .NET assembly =
is referenced on a program </FONT>
<BR><FONT SIZE=3D2>> > > running on Windows, the casing of the =
assembly name is </FONT>
<BR><FONT SIZE=3D2>> ignored, thus </FONT>
<BR><FONT SIZE=3D2>> > > when running the compiled program on =
Unix (or any real OS </FONT>
<BR><FONT SIZE=3D2>> :O), Mono </FONT>
<BR><FONT SIZE=3D2>> > > will fail to load the assembly if only =
one character </FONT>
<BR><FONT SIZE=3D2>> differs on the </FONT>
<BR><FONT SIZE=3D2>> > > case.</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Am I clear on this? Just to clarify my =
stupid english:</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > I have a Classpath.dll on Windows. I =
compile the program with:</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > mcs /r:classpath chachacha.cs</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > which ends successfully.</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Then when I run the prog in Linux, =
mono fails because it doesn't </FONT>
<BR><FONT SIZE=3D2>> > > find classpath.dll, and this is solved =
renaming the dll, </FONT>
<BR><FONT SIZE=3D2>> but this is </FONT>
<BR><FONT SIZE=3D2>> > > just annoying.</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Fill a bug report I should?</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > --</FONT>
<BR><FONT SIZE=3D2>> > > Pablo Baena =
<pbaena@uol.com.ar></FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> > Mono-list maillist - =
Mono-list@ximian.com </FONT>
<BR><FONT SIZE=3D2>> > <A =
HREF=3D"http://lists.ximian.com/mailman/listinfo/mono-list">http://lists.=
ximian.com/mailman/listinfo/mono-list</A></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> Mono-list maillist - =
Mono-list@ximian.com </FONT>
<BR><FONT SIZE=3D2>> <A =
HREF=3D"http://lists.ximian.com/mailman/listinfo/mono-list">http://lists.=
ximian.com/mailman/listinfo/mono-list</A></FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C2B777.7D23BFA2--