[Mono-list] VFAT vs Unix filesystems...

[Simon Waite]

I maintain the premise that dumbing down the DLL search method is a
"Bad Idea"(tm) - depending on which strategy you use to lookup
MyAssembly.dll.

For instance a malicious user could insert MYASSEMBLY.DLL into the 
search path, and override the assembly the app is taking. - Possibly
with disasterous concequences.

Of course the most likely story is that someone will accidently have
this problem, and spend days figuring it out. Regardless if you do 
dumb down the FS in mono ,leaving it as-is presents a similar problem
it has to be written in the documentation in LARGE LETTERS.

As for GAC, I'm not even sure any discussion documents wrt unix 
implementations are even about. I know for one, that I'd not want
mono being suid and handling all the assemblies for a cache.

The most likely case being is something like a .mono/gac directory
for each user, with a /var/share/mono/gac for system-wide officially
sanctioned assemblies - maybe.


Just my 2p

-S

----- Original Message ----- 
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...


> My two cents (since everyone else has already given theirs...)
> 
> Mono should be case-insensitive for all assembly name lookups.
> 
> Why?  Compatibility.  And it makes sense.  Here's why.
> 
> Long term (IIRC) we'll be following .NET.  Which means we'll have the
> concept of shared assemblies (located in the Global Assembly Cache
> (GAC)) and non-shared assemblies, located in the same directory (or a
> sub-directory) as the executable.
> 
> The GAC stores an assemblies version, locale, public key, etc., along
> with the assemblies file name.  This allows multiple different vendors
> to have a shared assembly with the same name (e.g. MySharedAssembly.dll)
> installed at the same time, since the public key *must* be different
> (different vendors).  Likewise for two different versions of a shared
> assembly from the same vendor: the version will be different, so you'll
> have to store multiple copies.
> 
> End result: for shared assemblies, you can't just use case-sensitive
> name comparisons anyway, since you need to take the version, public key,
> etc. into consideration.  For shared assemblies, case-insensitive name
> comparisons are the least of our worries, so we can always use
> case-insensitive searches.
> 
> That leaves local/non-shared assemblies.  Since these will be in the
> application's directory, we could argue that name casing is irrelevant,
> so just use case-sensitive names.  However, when would case-sensitive
> names be important for a single executable?  When you have
> ``Assembly.dll'' and ``assembly.dll'' used by the same program.  Unless
> they're in different sub-directories, this likely won't operate properly
> under .NET since Windows will only see one of those files, not both. 
> Plus, it would be brain-dead/stupid for a developer to do that, so I
> don't see much point in supporting that behavior.
> 
> So, *long-term*, I think case-insensitive searches should be the
> default.  However, before we get there we need to implement GAC support
> and the rest of the assembly-loading algorithms.
> 
> Short term, stick with the current behavior.  We should focus on correct
> long-term behavior instead of worrying about short-term hacks.
> 
>  - Jon
> 
> On Tue, 2003-01-07 at 20:21, Pablo Baena wrote:
> > I've noticed that when a .NET assembly is referenced on a program
> > running on Windows, the casing of the assembly name is ignored, thus
> > when running the compiled program on Unix (or any real OS :O), Mono
> > will fail to load the assembly if only one character differs on the
> > case.
> > 
> > Am I clear on this? Just to clarify my stupid english: 
> > 
> > I have a Classpath.dll on Windows. I compile the program with:
> > 
> > mcs /r:classpath chachacha.cs
> > 
> > which ends successfully.
> > 
> > Then when I run the prog in Linux, mono fails because it doesn't find
> > classpath.dll, and this is solved renaming the dll, but this is just
> > annoying.
> > 
> > Fill a bug report I should?
> > 
> > -- 
> > Pablo Baena <pbaena@uol.com.ar>
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list