Confused by Security Exception 1

[jmeckley]

scenario.
1. user places csv file in directory
2. user runs console app
3. console app modifies csv, then loads csv into db

the app runs fine locally, but on the shared drive I get the following exception. The appears to be happening when attempt to overwrite the file. the only people using this are Domain Admins.

below is the code and stack trace

private void RemoveHeaders()
{
	string[] dataWithHeaders = File.ReadAllLines(sourceFile);
	int headerIndex = FindIndexOfHeader(dataWithHeaders);

	string[] dataWithoutHeaders = new List<string>(dataWithHeaders)
		.GetRange(headerIndex, dataWithHeaders.Length - headerIndex)
		.ToArray();

	[COLOR=red]File.WriteAllLines(sourceFile, dataWithoutHeaders);[/color]
	Log.Info("removed headers. {0} rows remain.", dataWithoutHeaders.Length - 1);
}

System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
   at System.Security.CodeAccessPermission.Demand()
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.StreamWriter.CreateFile(String path, Boolean append)
   at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
   at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding)
   at System.IO.File.WriteAllLines(String path, String[] contents, Encoding enco
ding)
   at AccessControlDataImport.Con.Source.RemoveHeaders()
   at AccessControlDataImport.Con.Source.GetDataFrom(String source)
   at AccessControlDataImport.Con.Program.Main()
The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.Permissions.FileIOPermission
The Zone of the assembly that failed was:
Intranet

I've never encountered this before. And most of my googling returns asp.net issues. Has anyone dealt with this before?

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[NESWalt]

Are you accessing the file via drive letter or UNC?

I've run into issues when writing log files to "shared" or "virtual" drives on a server. For example, I have a service that runs at intervals based on XML input, and the logs it generates can't be written to the "E:" drive because it is not physically a drive. Since it wasn't much of an issue, I just instead put the logs on a F: drive (which is physically a drive).

I thought about modifying the CAS policy on the machine, but decided not to since I had an easy out. It seemed like to me at the time it was an untrusted issue.

 

[GoTerps88]

Windows or Console apps won't run off of the network drive. I gave the assembly a strong name and gave the assembly FULL TRUST using the .NET Framework Configuration Tool. I put it in the intranet zone code group and used the strong name as the membership condition.

This worked for me for a windows application.

 

[GoTerps88]

I should have said that Windows or Console apps won't run off the Network drive unless you apply full trust to them. I believe Microsoft was trying to prevent a security threat by not allowing executables to run unabated on a network share.

 

[jmeckley]

interesting. As a workaround we are running the console locally. I'll keep this in my pocket for future projects.

Does full trust require strong names? or can I just check some box off that says it's full trust?

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[GoTerps88]

In the ClickOnce security settings in the Project Properties Security tab you can elect to grant the assembly full trust by clicking the check box.

It's not a requirement to give an assembly a strong name in order to grant it full trust. But by giving the assembly a strong name, it bypasses some of the security checks that throws some of the Security exceptions.

I wouldn't qualify myself as an expert on .NET Security. It's a fairly labyrinthine subject. I just learned enough to get the job done

I find that few .NET developers have a grasp of .NET Security and it's often glossed over by books.