Code Access Security

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a Windows project (VB.net) that has two forms. The first form performs
some I/O operations and displays some SQL data on a third party grid (Janus).
It also contains a button that opens the second form.
The second form reads some SQL data and also displays in another grid (Janus).

This application, once deployed, will be accessed on a shared drive in the
network.
While trying to run it from a remote computer on the network, I kept getting
code access security errors due to the assembly not having rights to perform
certain operations.

I did some research and learned how to create a key and assign a strong name
to my assembly. Then, as a test, using the .NET Configuration tool, I created
a code group called MyTestCodeGroup and assigned the Everthing Permission Set
to my assembly.

Well, that allowed the application to perform all actions on the first form,
but when I go to access the second form, I get access security errors once
again.
I tried changing the Membership Condition to include All Code, but that
didn't fix the problem.

I also added the directive <Assembly:
AssemblyKeyFileAttribute("..\..\sgKey.snk")> to AssemblyInfo.vb and added
references to the System.Reflection and System.Runtime.InteropServices
classes.

If anyone can help, please keep in mind that I am still learning how the CLR
deals with code security and so far, this has been a somewhat complicated
process.

Thanks in advance,

Rod
(e-mail address removed)
 
Hi Sijin,

Thanks for replying.

Here's the message:
"The application attempted to perform an operation not allowed by the
security policy. The opration required the SecurityException. To grand this
application the required permission please contact your system administrator,
or use the Microsoft .NET security policy administration tool.
If you click Continue, the application will ignore this error and attempt to
continue. If you click Quit, the application will be shut down immediately.
Security Error."
 
I'm assuming you typed that in rather than cut and paste it - -so do you mean it required the SecurityPermission?

Does your code use interop?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi Sijin,

Thanks for replying.

Here's the message:
"The application attempted to perform an operation not allowed by the
security policy. The opration required the SecurityException. To grand this
application the required permission please contact your system administrator,
or use the Microsoft .NET security policy administration tool.
If you click Continue, the application will ignore this error and attempt to
continue. If you click Quit, the application will be shut down immediately.
Security Error."
 
I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from Microsoft
regarding creating Strong Names for assemblies.
 
Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a reference to any assemblies. The interop layer is contained in mscorlib which you will already be referencing. You don't need InteropServices to do strong naming - you need the reflection namespace for the AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare statements, etc) then this would be the cause of your exception as the interop layer will issue a demand for a SecurityPermission for unmanaed code access. Partially trusted code doesn't get this permission by default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from Microsoft
regarding creating Strong Names for assemblies.
 
I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The failing
part of this app is just another form trying to load a grid with SQL data.
All built in .NET, part of the same project.
 
The error message you are seeing looks like a Winforms default one - can you trap the exception nearer teh site that it happens (maybe where you show the other form (if you call ShowDialog on it) so we can have a look at the exception trace and see what is generating the SecurityException

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The failing
part of this app is just another form trying to load a grid with SQL data.
All built in .NET, part of the same project.

Richard Blewett said:
Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a reference to any assemblies. The interop layer is contained in mscorlib which you will already be referencing. You don't need InteropServices to do strong naming - you need the reflection namespace for the AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare statements, etc) then this would be the cause of your exception as the interop layer will issue a demand for a SecurityPermission for unmanaed code access. Partially trusted code doesn't get this permission by default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from Microsoft
regarding creating Strong Names for assemblies.
Click to expand...

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
 
I notice that you stated that you assigned the "Everything" permission set.
Note that this is *not* the same as "Full Trust". So you will not be able
to call into anything that does not allow partially trusted callers. See if
switching to "Full Trust" fixes your issue. If so, the problem is probably
a call you're making that does not allow partial trust. (Much of the "core"
FCL does not allow partialy trusted callers, so a plain .net app "out of the
box" could see this issue)

--
-Philip Rieck
http://philiprieck.com/blog/

-
Richard Blewett said:
The error message you are seeing looks like a Winforms default one - can
you trap the exception nearer teh site that it happens (maybe where you
show the other form (if you call ShowDialog on it) so we can have a look
at the exception trace and see what is generating the SecurityException

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog


nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The
failing
part of this app is just another form trying to load a grid with SQL data.
All built in .NET, part of the same project.

Richard Blewett said:
Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a
reference to any assemblies. The interop layer is contained in mscorlib
which you will already be referencing. You don't need InteropServices to
do strong naming - you need the reflection namespace for the
AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare
statements, etc) then this would be the cause of your exception as the
interop layer will issue a demand for a SecurityPermission for unmanaed
code access. Partially trusted code doesn't get this permission by
default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from Microsoft
regarding creating Strong Names for assemblies.
Click to expand...

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
Click to expand...
 
I think I figured out part of the issue... a bit of an oversight on my part,
as it usually goes. The way I set up to test this was the following: I'd
place the installed program on my development machine, then I created a
shared folder and placed a shortcut to the .exe in it. I'd then log on to
another machine with a test user account and try to run this program, thus
causing the aformentioned error.
What I didn't realize (which it turned out to be a new nuissance altogether)
is that I had to configure the setting in the .NET Configuration Tool on the
CLIENT machine, and not the machine hosting the code.
I set the Permission Set to "Full Trust" as you recommended and everything
works beautifully.
However, this posts a new question: Will I have to go though every client
machine and adjust these settings in order to allow users to run this
remotely?
That would certainly be most inneficient.
I'd appreciate you guys hang with me on this issue.

Regards,

Rod

Philip Rieck said:
I notice that you stated that you assigned the "Everything" permission set.
Note that this is *not* the same as "Full Trust". So you will not be able
to call into anything that does not allow partially trusted callers. See if
switching to "Full Trust" fixes your issue. If so, the problem is probably
a call you're making that does not allow partial trust. (Much of the "core"
FCL does not allow partialy trusted callers, so a plain .net app "out of the
box" could see this issue)

--
-Philip Rieck
http://philiprieck.com/blog/

-
Richard Blewett said:
The error message you are seeing looks like a Winforms default one - can
you trap the exception nearer teh site that it happens (maybe where you
show the other form (if you call ShowDialog on it) so we can have a look
at the exception trace and see what is generating the SecurityException

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog


nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The
failing
part of this app is just another form trying to load a grid with SQL data.
All built in .NET, part of the same project.

Richard Blewett said:
Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a
reference to any assemblies. The interop layer is contained in mscorlib
which you will already be referencing. You don't need InteropServices to
do strong naming - you need the reflection namespace for the
AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare
statements, etc) then this would be the cause of your exception as the
interop layer will issue a demand for a SecurityPermission for unmanaed
code access. Partially trusted code doesn't get this permission by
default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from Microsoft
regarding creating Strong Names for assemblies.



:

I'm assuming you typed that in rather than cut and paste it - -so do
you mean it required the SecurityPermission?

Does your code use interop?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
Click to expand...

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
Click to expand...
Click to expand...
 
Two things:

1) maybe work out why your app *requires* full trust to run. It maybe something you can do another way and allow yourself to run partially trusted (this is the best option IMO)

2) You can distribute an enterprise policy via the enterprisesec.config (which does in the same directory as security.config) its purpose is to allow policy to be set on many machines from remotely

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I think I figured out part of the issue... a bit of an oversight on my part,
as it usually goes. The way I set up to test this was the following: I'd
place the installed program on my development machine, then I created a
shared folder and placed a shortcut to the .exe in it. I'd then log on to
another machine with a test user account and try to run this program, thus
causing the aformentioned error.
What I didn't realize (which it turned out to be a new nuissance altogether)
is that I had to configure the setting in the .NET Configuration Tool on the
CLIENT machine, and not the machine hosting the code.
I set the Permission Set to "Full Trust" as you recommended and everything
works beautifully.
However, this posts a new question: Will I have to go though every client
machine and adjust these settings in order to allow users to run this
remotely?
That would certainly be most inneficient.
I'd appreciate you guys hang with me on this issue.

Regards,

Rod
 
If the machines are in an AD, you can distribute new settings through GPO.

But yes, each client must have the .net framework security changes applied.

--
-Philip Rieck
http://philiprieck.com/blog/

-
tuuky said:
I think I figured out part of the issue... a bit of an oversight on my
part,
as it usually goes. The way I set up to test this was the following: I'd
place the installed program on my development machine, then I created a
shared folder and placed a shortcut to the .exe in it. I'd then log on to
another machine with a test user account and try to run this program, thus
causing the aformentioned error.
What I didn't realize (which it turned out to be a new nuissance
altogether)
is that I had to configure the setting in the .NET Configuration Tool on
the
CLIENT machine, and not the machine hosting the code.
I set the Permission Set to "Full Trust" as you recommended and everything
works beautifully.
However, this posts a new question: Will I have to go though every client
machine and adjust these settings in order to allow users to run this
remotely?
That would certainly be most inneficient.
I'd appreciate you guys hang with me on this issue.

Regards,

Rod

Philip Rieck said:
I notice that you stated that you assigned the "Everything" permission
set.
Note that this is *not* the same as "Full Trust". So you will not be
able
to call into anything that does not allow partially trusted callers. See
if
switching to "Full Trust" fixes your issue. If so, the problem is
probably
a call you're making that does not allow partial trust. (Much of the
"core"
FCL does not allow partialy trusted callers, so a plain .net app "out of
the
box" could see this issue)

--
-Philip Rieck
http://philiprieck.com/blog/

-
Richard Blewett said:
The error message you are seeing looks like a Winforms default one -
can
you trap the exception nearer teh site that it happens (maybe where you
show the other form (if you call ShowDialog on it) so we can have a
look
at the exception trace and see what is generating the SecurityException

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog


nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The
failing
part of this app is just another form trying to load a grid with SQL
data.
All built in .NET, part of the same project.

:

Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a
reference to any assemblies. The interop layer is contained in
mscorlib
which you will already be referencing. You don't need InteropServices
to
do strong naming - you need the reflection namespace for the
AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare
statements, etc) then this would be the cause of your exception as
the
interop layer will issue a demand for a SecurityPermission for
unmanaed
code access. Partially trusted code doesn't get this permission by
default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from
Microsoft
regarding creating Strong Names for assemblies.



:

I'm assuming you typed that in rather than cut and paste it - -so
do
you mean it required the SecurityPermission?

Does your code use interop?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog




---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
Click to expand...
Click to expand...
Click to expand...
 
Your help was much appreciated!!!
Thank you gentlemen... please vote (if you can) in this most important
coming election.

Cheers!

"More important than the quest for certainty is the quest for clarity"

Philip Rieck said:
If the machines are in an AD, you can distribute new settings through GPO.

But yes, each client must have the .net framework security changes applied.

--
-Philip Rieck
http://philiprieck.com/blog/

-
tuuky said:
I think I figured out part of the issue... a bit of an oversight on my
part,
as it usually goes. The way I set up to test this was the following: I'd
place the installed program on my development machine, then I created a
shared folder and placed a shortcut to the .exe in it. I'd then log on to
another machine with a test user account and try to run this program, thus
causing the aformentioned error.
What I didn't realize (which it turned out to be a new nuissance
altogether)
is that I had to configure the setting in the .NET Configuration Tool on
the
CLIENT machine, and not the machine hosting the code.
I set the Permission Set to "Full Trust" as you recommended and everything
works beautifully.
However, this posts a new question: Will I have to go though every client
machine and adjust these settings in order to allow users to run this
remotely?
That would certainly be most inneficient.
I'd appreciate you guys hang with me on this issue.

Regards,

Rod

Philip Rieck said:
I notice that you stated that you assigned the "Everything" permission
set.
Note that this is *not* the same as "Full Trust". So you will not be
able
to call into anything that does not allow partially trusted callers. See
if
switching to "Full Trust" fixes your issue. If so, the problem is
probably
a call you're making that does not allow partial trust. (Much of the
"core"
FCL does not allow partialy trusted callers, so a plain .net app "out of
the
box" could see this issue)

--
-Philip Rieck
http://philiprieck.com/blog/

-
The error message you are seeing looks like a Winforms default one -
can
you trap the exception nearer teh site that it happens (maybe where you
show the other form (if you call ShowDialog on it) so we can have a
look
at the exception trace and see what is generating the SecurityException

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog


nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I see what you're saying Richard.
No COM objects... that's the weird thing about this whole mess. The
failing
part of this app is just another form trying to load a grid with SQL
data.
All built in .NET, part of the same project.

:

Hmm ... but you don't actually do any interop?

Imports just saves you some typing it doesn't actually create a
reference to any assemblies. The interop layer is contained in
mscorlib
which you will already be referencing. You don't need InteropServices
to
do strong naming - you need the reflection namespace for the
AssemblyKeyFile attribute though.

If you actually do any interop (use COM objects, have Declare
statements, etc) then this would be the cause of your exception as
the
interop layer will issue a demand for a SecurityPermission for
unmanaed
code access. Partially trusted code doesn't get this permission by
default and so you would get a SecurityException.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

I did type it in :)
I do have a reference (Imports) to System.Runtime.InteropServices in
AssemlyInfo.vb
I only added that reference as I saw it in the help files from
Microsoft
regarding creating Strong Names for assemblies.



:

I'm assuming you typed that in rather than cut and paste it - -so
do
you mean it required the SecurityPermission?

Does your code use interop?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog




---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
Click to expand...
Click to expand...
Click to expand...
 
Back
Top