Bug or Feature

 A strange thing happened today, I was implementing a small security package for my app. The project file was called Security and it created a Security.Dll file as output. I compiled and ran and BOOM no connection to the database!!! … I am thinking how can adding a new module totally unrelated lead to DB connectivity problems…So I do the usual checks, network connectivity, name resolution, I can connect thru enterprise manager, I can connect using SQL authentication. It seems that when I try to connect using SSPI I get the exception “Cannot initialize SSPI package”….Oh Boy…I am thinking corrupt memory, hard disk what could have happened, is my .Net installation corrupt?...So as any good windows user would do..i reboot…no help…problem persists. Its been an hour and I have only allocated 30 mins…someone suggests trying an earlier build….i think..well let’s give it a try..Viola it works…Light goes on…it has to be the security module, because that is the only change….i change the name of the project output to XXXSecurity.Dll and it works. Problem solved!! What a rush…Ahhh the joys of fixing problems.

Then I start to think, if .Net chooses the Security.Dll in my folder then couldn’t someone else just put a fake Security.Dll in an application folder and override all Code Access Security!! I seriously hope this is a gap in my understanding rather than a bug in my beloved framework.

6 Comments

  • I cannot find the KB article, but we ran into the same thing. We ended up finding out that you cannot reference an assembly named Security.dll. It has no bearing on CAS at all though.

  • That's because there'a a DLL in your System32 directory called "security.dll" - this is the one that is used to do SSPI.



    The LoadLibrary documentation states that the application directory is searched before the system directory. This is by design so you can include your desired version of say the VB runtime without getting roached by somebody else installing VB N+1 into the system32 directory.



    As for the security implications: When you install your program you shouldn't give everybody write permission into its directory.

  • I still have to see an application that write protects it's installation directory. I am talking about shrinwrapped software. With customized internal software maybe that is possible.



    So does that mean that it is infact possible to replace security.dll with one's own implementation, i wonder what other libs can be replaced as such if possible. I am going to try and run security.dll thru ILDASM change it and see what works.

  • We ran into exactly the same problem many moons ago. How many man-hours have been wasted hunting this problem down? The VS.NET IDE group should just prevent naming a dll Security!

  • "I still have to see an application that write protects it's installation directory." -- hmm, everything in my Program Files directory is read-only to users. At any rate, what's the issue in doing that for shrinkwrapped software?

  • Michael Giagnocavo wrote: "At any rate, what's the issue in doing that for shrinkwrapped software?"



    Sadly, because a lot of shrinkwrapped software still lives (in the minds of their developers) in the pre-multi-user era (circa 1995) of using INI files, and keeping data stores in the program installation directory.



    Most of the multimedia applications I have tried are like this, even big name companies. Some throw the dummy if users have not got write access to the INI files even when nothing is being written to them.



    Most people don't worry about it because they are happy to run as Administrators, but try and set up your machine at home to be secure with a seperate account for each user with child accounts restricted and you'll find the number one barrier to achieving a secure system with independant settings and working folders for each user will be the third party programs that believe doing things properly* is the "Microsoft way" and therefore should be avoided. Some Microsoft products are guilty of this as well, of course.



    Sadly, the made for Windows logo is not a lot of help when you have a task for which no major programs qualify and no-one is forced to meet the standards.



    *By this, I mean "when in Rome...". If you write a program to run on Linux, do it the Linux way, but on Windows do it the Windows way. There are proper ways that match the conventions for each OS.

Comments have been disabled for this content.