Deployment

  • Thread starter Thread starter Daniel F. Devine
  • Start date Start date
D

Daniel F. Devine

Hi,

We just finished our new Project in C# and wish to deploy the App. All is
well when we copy the assemblies to local drives BUT when the assemblies are
accessed from a network share users cannot login to the DB. No error is
generated - it simply sits there with the login form still active - pressing
the cancel button exits the App but throws a Security exception. Is this
expected behavior? If we use the SDK .NET tool to Adjust the .NET security
to FULL it works. Does this need to be done to all clients that will
attempt to access the App via the share? All clients DO have the .NET
runtime installed. Why isn't the security necessary via the local drive?
Can we automate the security feature for network shares? Additionally, are
there similiar security issues with a Citrix Server or a server running
Terminal Services?

Thanks for any insight you can share.
 
Daniel F. Devine said:
Hi,

We just finished our new Project in C# and wish to deploy the App. All is
well when we copy the assemblies to local drives BUT when the assemblies are
accessed from a network share users cannot login to the DB. No error is
generated - it simply sits there with the login form still active - pressing
the cancel button exits the App but throws a Security exception. Is this
expected behavior? If we use the SDK .NET tool to Adjust the .NET security
to FULL it works. Does this need to be done to all clients that will
attempt to access the App via the share? All clients DO have the .NET
runtime installed. Why isn't the security necessary via the local drive?
Can we automate the security feature for network shares? Additionally, are
there similiar security issues with a Citrix Server or a server running
Terminal Services?
Click to expand...

An assembly located on a share is in a different security zone than if it
were on a local disk.

Check out Code Access Security in the .NET Framework Developer's Guide
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
ml/cpconcodeaccesssecurity.asp?frame=true).
 
John Saunders said:
this?

It seems like the application is trying to do something it's not permitted
to do, and is handling the failure badly. That's why it's "just sitting
there". I bet if you ran it in the debugger and interrupted it at this time,
you'd see it isn't "just sitting there".

UI display permissions are granted to applications in the Intranet zone.
Click to expand...

John -

Thanks, you are correct. The App was throwing a Security Exception that the
exception handler was "eating up" but not displaying because the handler was
coded to look for a FileIOException. The SecurityException occurs at the
point of an object method invocation - which serves to verify login
credentials. It never gets to this code - so now I ask - I can construct
the object in this security zone(network share), but not invoke a method? I
did not see this limitation in the Security White Paper. Thanks for your
help and patience on this - we are very new to this environment and more so
in this security world we now live.
 
Daniel F. Devine said:
John -

Thanks, you are correct. The App was throwing a Security Exception that the
exception handler was "eating up" but not displaying because the handler was
coded to look for a FileIOException. The SecurityException occurs at the
point of an object method invocation - which serves to verify login
credentials. It never gets to this code - so now I ask - I can construct
the object in this security zone(network share), but not invoke a method? I
did not see this limitation in the Security White Paper. Thanks for your
help and patience on this - we are very new to this environment and more so
in this security world we now live.
Click to expand...

Daniel,

I'm afraid I'm going to have to leave the details of this to someone else -
I haven't yet had to deal with running assemblies from a share. The last
time it happened, it was an error, and I just copied the assembly locally!

I would recommend you take a look at the ".NET Framework Configuration" tool
under Start->Programs->Administrative Tools. Examining the Permission Sets
may prove interesting to you. For instance, on my machine, code in the Local
Intranet Zone gets the permission set "LocalIntranet", which includes:

* Environment Variables: Can read "USERNAME"
* File Dialog: Unrestricted
* Isolated Storage File: Assembly Isolation By User with a disk quota of
9223372036854775807
* Reflection: Member Access: No, Type Information: No, Reflection Emit:
Yes
* Security: Enable Code Execution, Assert any permission that has been
granted, and No to everything else
* User Interface: Unrestricted
* DNS: Yes
* Printing: Default Printing
* Event Log: Instrument this machine

You can increase the permissions granted to particular assemblies. See .NET
Framework Configuration Tool (Mscorcfg.msc)
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/ht
ml/cpconnetframeworkadministrationtoolmscorcfgmsc.asp) for some information.

Good Luck,
John Saunders
Internet Engineer
(e-mail address removed)
 
Hello Daniel,

Thanks for posting in the group.

To answer your questions, I suggest you read one MSDN artilce by Don Box.
"The Security Infrastructure of the CLR Provides Evidence, Policy,
Permissions, and Enforcement Services"
http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityinNET/

In this article, Don Box explains how code access security works in the
CLR. He discusses the kinds of evidence required by policy, how permissions
are granted, and how policy is enforced by the runtime.

Code access security uses a configurable security policy to grant
permissions to code based on evidence. While the CLR implicitly enforces
some aspects of security policy, it is the job of trusted libraries to
enforce security explicitly, using either imperative programmatic
interfaces or declarative attributes. I think this article is a good start
on code access security.

Hope that helps.


Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
!From: "Daniel F. Devine" <[email protected]>
!References: <[email protected]>
<[email protected]>
<#[email protected]>
<#[email protected]>
!Subject: Re: Deployment
!Date: Fri, 22 Aug 2003 14:19:18 -0400
!Lines: 33
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <[email protected]>
!Newsgroups: microsoft.public.dotnet.framework
!NNTP-Posting-Host: 204.251.174.22
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework:51984
!X-Tomcat-NG: microsoft.public.dotnet.framework
!
!
!!> > without throwing a Security exception? Do you have any thoughts on
!this?
!>
!> It seems like the application is trying to do something it's not
permitted
!> to do, and is handling the failure badly. That's why it's "just sitting
!> there". I bet if you ran it in the debugger and interrupted it at this
!time,
!> you'd see it isn't "just sitting there".
!>
!> UI display permissions are granted to applications in the Intranet zone.
!> --
!> John Saunders
!> Internet Engineer
!> (e-mail address removed)
!>
!>
!
!John -
!
!Thanks, you are correct. The App was throwing a Security Exception that
the
!exception handler was "eating up" but not displaying because the handler
was
!coded to look for a FileIOException. The SecurityException occurs at the
!point of an object method invocation - which serves to verify login
!credentials. It never gets to this code - so now I ask - I can construct
!the object in this security zone(network share), but not invoke a method?
I
!did not see this limitation in the Security White Paper. Thanks for your
!help and patience on this - we are very new to this environment and more so
!in this security world we now live.
!
!
!
 
Back
Top