Different Permissions For Forms Control in Internet Explorer Applied

  • Thread starter Thread starter Markus Kling
  • Start date Start date
M

Markus Kling

Hi,

I have a Windows Forms Control running within the Internet Explorer.

The application is able to download files from a remote store via drag and
drop to the local filesystem. Some details:

- The files are selected from a ListView

- ListView.ItemDrag
- calculates a temporary filename (beneath Path.GetTempPath()) for each of
the selected files
- and creates the necessary DataObject structure with DataFormts.FileDrop
and DragDropEffects.Move

- ListView.QueryContinueDrag watches for the DragAction.Drop event and than
downloads the file(s) content from the remote location to the calculated
temporary filename. The file does not exist prior to this point.

Due to several circumstances the application is assigned FullTrust via the
StrongName condition. All is running smoothly under .Net 1.1.

For .Net 2.0 with equal security settings the temporary file is not moved
from its temporary location to the drop location. To be clear: this is not
done by the application itself but the Windows Explorer.

Now comes the mistery:

- With security turned off completly (caspol -s off) the application works
- With a UrlCondition attached to the complete webserver (not only the
controls dll location) the application works
- http://servername/path/name.dll does not work
- http://servername/path/* does not work
- http://servername/* works


Why is fulltrust not fulltrust?
Any ideas?

Thanks for your help,
Markus


==================================
caspol -a -resolveperm http://... path to dll
==================================
Resolving permissions for level = Enterprise
Resolving permissions for level = Machine
Resolving permissions for level = User

Grant =
<PermissionSet class="System.Security.PermissionSet"
version="1"
Unrestricted="true"/>

==================================
caspol -a -resolvegroup http://... path to dll
==================================
Level = Enterprise
Code Groups:
1. All code: FullTrust

Level = Machine
Code Groups:
1. All code: Nothing
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.6. StrongName -
0024000004800000940000000602000000240000525341310004000001
0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE
E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50
5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C
CC2968AC2D3AA11DFB1FBB: FullTrust

Level = User
Code Groups:
1. All code: FullTrust
 
Hi Markus,

Thank you for posting.

This is a quick note to let you know that I am performing research on this
issue and will get back to you as soon as possible. I appreciate your
patience.


Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Is the 1.1 vs 2.0 difference being observed on identical assemblies, or did
you make some code changes for the 2.0 version? If the latter, you may want
to take a look at
http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx to see if any of
your changes might have impacted on the effect permission grant. For
example, if your code uses assertions to work around the AppDomain
permission limitation, and you've marked your 2.0 assembly as
SecurityTransparent, your assertions will not work.

If the problem is being observed on the same assembly, might it be that the
1.1 CAS policy is granting extended permissions based on something other
than the strong name (e.g.: local intranet zone granted full trust)? If
not, are any exception being thrown and, if so, could you please post the
full exception details (incl. call stack listing), as returned by its
ToString method?
 
Hi Nicole,

thanks for your answers. I allready knew that fabulous post ;)

To answer your questsion:
- All security permissions (1.1 & 2.0) are not touched except adding the
described strong memebership codegroup. You can find the output from caspol
for the remote location of the dll attached to my last post
- As described the code runs perfect with equal permissions using the .Net
1.1 VM
- There are no exceptions thrown at any point. I even stepped through the
whole drag&drop code using a debugger... nothing!

As mensioned, the code does a WebService-Call and stores the returned
content to a temporary file location which should than be moved by native
code from the explorer processes to the drop location. The temporary file is
created correctly event with the file contents but the explorer only moves
the created file under the following circumstances:

- With security turned off completly (caspol -s off) the application works
- With a UrlCondition attached to the complete webserver (not only the
controls dll location) the application works
- http://servername/path/name.dll does not work
- http://servername/path/* does not work
- http://servername/* works


That's totally confusing me!
Markus
 
Linda,

you find additional information in my answer to Nicoles reply.

Thanks for your help,
Markus
 
What does the caspol output look like on the 1.1 machine? Also, is fx 1.1
installed on the fx 2.0 machine? If so, are you sure that you've modified
the CAS policy for 2.0 instead of 1.1 on that machine? If you're sure that
you've modified the 2.0 policy, might it happen to be a 64-bit machine? If
so, did you run the 32-bit or 64-bit version of caspol?
 
Nicole,

What does the caspol output look like on the 1.1 machine?

<PermissionSet class="System.Security.PermissionSet"
version="1"
Unrestricted="true">
<IPermission class="System.Security.Permissions.SiteIdentityPermission,
mscor
lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Site="<site>"/>
<IPermission
class="System.Security.Permissions.StrongNameIdentityPermission,
mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

version="1"
PublicKeyBlob="0024000004800000940000000602000000240000525341310
0040000010001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6
ED165DFFEE84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F
559A54A505CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCC
AC4D96E2CCC2968AC2D3AA11DFB1FBB"
Name="<dll name>"
AssemblyVersion="1.7.2355.17871"/>
<IPermission class="System.Security.Permissions.UrlIdentityPermission,
mscorl
ib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Url="<... dllpath ... >"/>
<IPermission class="System.Security.Permissions.ZoneIdentityPermission,
mscor
lib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Zone="Intranet"/>
</PermissionSet>


Also, is fx 1.1 installed on the fx 2.0 machine?
Yes

If so, are you sure that you've modified the CAS policy for 2.0 instead of
1.1 on that machine?
Yes, they are both modified.

If you're sure that you've modified the 2.0 policy
Yes, definitly.

Might it happen to be a 64-bit machine?
No, 32 bit OS
 
Sorry, I meant a caspol -a -resolvegroup output, like the one you included
in your first message. Also, could you please confirm whether the problem
is being observed on _exactly_ the same assembly or whether it has been
modified in _any_ way (including recompilation with VStudio 2005) for 2.0.
 
1) Sorry, I meant a caspol -a -resolvegroup output, like the one you
included in your first message.

Level = Enterprise
Code Groups:

1. All code: FullTrust
Level = Machine

Code Groups:
1. All code: Nothing
1.1. Zone - Intranet: LocalIntranet
1.1.1. All code: Same site Web.
1.1.2. All code: Same directory FileIO - Read, PathDiscovery
1.5. StrongName -
0024000004800000940000000602000000240000525341310004000001
0001009FE4E630CDE5D1309A7B2EA0196776663F30618D995FCBC564CCDA330C08022C6ED165DFFE
E84D7D8214E96EE7FE1B0A469344EECB010A9345B40132BC0991F9830851504AFACD13F559A54A50
5CD2E206A6A38C4D8E6C00F64DF16E92657E4A75E67E0FE57276C986239F2BC9D6E6DCCAC4D96E2C
CC2968AC2D3AA11DFB1FBB: FullTrust

Level = User
Code Groups:
1. All code: FullTrust


2) Is being observed on _exactly_ the same assembly or whether it has been
modified in _any_ way (including recompilation with VStudio 2005) for 2.0.

Yes! The machines running the dll for test purposes are even fresh installed
VPCs only having the latest servicepacks and .Net Framework installed.
 
Sorry, my answer was a bit mistakable. The dll is .Net 1.1 compilated and
has not been touched in any of the described cases.
 
I suspect that the problem is likely due to the changes in delegate
behaviour described at http://blogs.msdn.com/eugene_bobukh/default.aspx
(and masked by a lovely bit of exception swallowing on the part of
Control.DoDragDrop). If the new delegate creation-time cacheing does not
take assertions into account (as would appear to be the case), there's
essentially nothing you can do in your code to avoid the issue you are
seeing. Instead, you would need to modify CAS policy to grant additional
permissions based on URL evidence rather than strong name evidence.
 
"Does not take assertions into account": Ihmo an assertion must prevent the
stackwalk. Such this behavior would be wrong. Am I missing something.

I think rather than the security that the change in Control.DoDragDrop to
not masquerade all exceptions forces the native code to stop.

What to do now?
File a bug?

Markus
 
Markus Kling said:
"Does not take assertions into account": Ihmo an assertion must prevent
the stackwalk. Such this behavior would be wrong.
Click to expand...

Inconvenient, but perhaps not "wrong". Depends on what the CLR designers
decided would be appropriate in this scenario.
Am I missing something.
Click to expand...

Unfortunately, since there's very little documentation available on the
subject, it's quite difficult to know what the intended behaviour might be.

I think rather than the security that the change in Control.DoDragDrop to
not masquerade all exceptions forces the native code to stop.

What to do now?
File a bug?
Click to expand...

Couldn't hurt--at least it might get the right people looking at the issue.
In the meantime, you do have a known solution for your immediate problem:
use URL evidence if the functionality cannot be changed.
 
Back
Top