VB.Net running on your network?

[Andi]

We have VB.Net installed on a few stations that are used to teach 6th formers programming. Since students are not allowed to run or contain exes in their home folders these pupils have designated folders that only they and the programming teacher have access to and I have set .net security to have full access to that share using the following script at startup.

 

%windir%\Microsoft.NET\Framework\v2.0.50727\caspol.exe -q -m -ag LocalIntranet_Zone -url \\theoden\shared\ FullTrust -n FullTrustShare

 

However, some of the students are getting missing manifest errors and there are other .Net related errors occuring. Attached are screenshots of the errors.

 

Has anyone come across and resolved this kind of thing before?

[SYNACK]

- Updated after re-reading the question -

 

This could be related to the permissions for debugging ie the access to the system library files to trace faults when it is in debugging mode. To test this you could try running the program without debugging.

 

I would test running, saving, compiling on the local system to be sure it is not related to the .net file system restrictions. If it is you could have a temporary folder on the local machine that the users programming directory is copied to on logon, this could copy the files back at log off. A bit of a mission but so is dealing with .net remote permissions.

[ChrisH]

To add to the above there is a specific local policy dealing with debugging rights etc. Maybe something to look at.

[Andi]

Thanks guys I'll look into the debugging thing and post back my results.

[Geoff]

Be aware that if you've given a user debugging rights, there's nothing to stop them getting local admin.

[Andi]

Oh really? I'm not going to go anywhere near that then.

 

I guess it's not really the sort of program that should be networked anyway.

[Geoff]

GetAdmin Info.

 

MS did eventually fix the bug, but users with debugging rights are immune to the 'fix' and can run getadmin successfully anyway.

[Andi]

Oh dear, I think I'd rather somehow get this on standalone machines then.

 

That's going to be a nightmare!

 

Cheers for the advice Geoff and all.

[PiqueABoo]

GetAdmin. MS did eventually fix the bug, but users with debugging rights are immune to the 'fix'

 

When I were a lad ..remember a hour or two on a Saturday disassembling getadmin (source code was released later) and figuring the quick workaround for that with a US NT security wiz. MS did fix it. And later Paul Leach of MS, the informal i/f to the then NT security "community" (and former Apollo Nix guy if that helps) told us they had subsequently had a full, lengthy audit of the kernel done. SeDebugPrivilege was really another issue and ultimately being able to do anything with that is "by design" for good reasons.

 

Anyway manifest errors can be lots of thing and the first screenshot looks like a genuine namespace problem i.e. something that can happen if you're not careful with those.

 

I'm not an expert on trusting shares, but I'm not sure about the caspol line. I have a batch to remember the comand line I once needed and it looks like this:

 

caspol.exe -m -ag 1.2 -url file://server/share/* FullTrust

 

A not uncommon solution to trying to develop code on a locked down machine is to give them a VM environment and revert that to a nice clean snapshot when they've finished breaking it.

[Andi]

I've been toying with that idea in my mind. Just a VM image of a clean XP standalone with Visual Studio that the students can fire up when they need to run the programs.

 

Thanks.