Reading a file from a UNC path in C#/.NET

[trs-ggcsea]

Hi,

I am reading a file from a UNC path in my Visual studio 2005 C# (.NET
2) program and getting an access denied exception. I am unsure if this
access denied is due to the .NET security model, or because I need to
implement impersonation of some sort. I was hoping someone could point
me to an answer or the appropriate documentation, as I have as yet been
unable to google up an answer.

The account the program is running under is an AD user account. Here
is an example of the code I am running:

// the following works correctly for a file that has few
// permission restrictions on it
FileStream fs = new
FileStream("\\\\server\\public\\publicfile.txt",FileMode.Open);

// the following throws an access denied exception for
// a file that has permission restrictions
// the file being access is readable only by domain users
// who are members of the "private" group
FileStream fs = new
FileStream("\\\\server\\private\\privatefile.txt",FileMode.Open);

From the above situation, I see I don't need to do anything special to

read from UNC paths, however, if there are permissions restrictions, it
looks like I need to do something but I am not sure what. I am leaning
towards impersonation.

TIA for any pointers.

John Holder

 

[Kevin Spencer]

the exception occurs because the account your app is running under doesn't
have the premission required to open the file. Yes, impersonation is the
solution. Here's an article that explains how:

http://www.codeproject.com/csharp/cpimpersonation1.asp

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

 

[trs-ggcsea]

the exception occurs because the account your app is running under doesn't
have the premission required to open the file. Yes, impersonation is the
solution. Here's an article that explains how:

http://www.codeproject.com/csharp/cpimpersonation1.asp

<SNIP>

I just noticed I had neglected to mention that the user accout *does*
have permission to read the file in question. For example, when I get
the exception, if I copy the path from the debugger and paste it into
an explorer window, I can read the file without any issue. Does the
above solution still apply in this situation? And if so, why?

I apologize for neglecting to include that above fact, as it demeaned
the value of the question.

John Holder

 

[sloan]

Are you sure?


//maybe this too//string threadIdentity =
Thread.CurrentPrincipal.Identity.Name;
string windowsIdentity = WindowsIdentity.GetCurrent().Name;

When you catch the exception , throw this into the logging.

That'll tell you who you are. You may not be who you are in development vs
deployed code.

 

[Robert Speck]

I am reading a file from a UNC path in my Visual studio 2005 C# (.NET

2) program and getting an access denied exception. I am unsure if this
access denied is due to the .NET security model, or because I need to
implement impersonation of some sort. I was hoping someone could point
me to an answer or the appropriate documentation, as I have as yet been
unable to google up an answer.

The account the program is running under is an AD user account. Here
is an example of the code I am running:

// the following works correctly for a file that has few
// permission restrictions on it
FileStream fs = new
FileStream("\\\\server\\public\\publicfile.txt",FileMode.Open);

// the following throws an access denied exception for
// a file that has permission restrictions
// the file being access is readable only by domain users
// who are members of the "private" group
FileStream fs = new
FileStream("\\\\server\\private\\privatefile.txt",FileMode.Open);

read from UNC paths, however, if there are permissions restrictions, it
looks like I need to do something but I am not sure what. I am leaning
towards impersonation.

The issue has nothing to do with C# or .NET. The simple story is that you
don't have the rights on the target machine to access "privatefile.txt". You
either need to impersonate someone who does have those rights, or otherwise
pass the credentials of someone who has the rights before connecting to the
server for the first time. Unfortunately, I'm not a C# or .NET expert so I
can't tell you off-hand which .NET classes to use (someone else can point
this out I'm sure - I can point you to the equivalent WinAPI functions if
you wish). In any case, the story actually runs deeper so if you're
producing a commercial application that may need to access a shared folder
then you really need to understand some of the finer points of NTLM
authentication, the SMB (Server Message Block) protocol (AKA LAN Manager),
and the Windows security model in general. It's actually not as hard as many
people think but it does take experience. You'ld be wise to find a security
expert to help but there are few of them around. I'd strongly suggest
getting hold of a copy of "Programming Windows Security" by Keith Brown. I'm
not sure if it's in print anymore (you can probably order it) but it's by
far the best security book I've ever read (written specifically for
programmers). Note that it also contains an entire chapter devoted to this
very subject (accessing shared resources using the Windows file server and
all the security issues involved)

 

[trs-ggcsea]

Are you sure?


//maybe this too//string threadIdentity =
Thread.CurrentPrincipal.Identity.Name;
string windowsIdentity = WindowsIdentity.GetCurrent().Name;

When you catch the exception , throw this into the logging.

That'll tell you who you are. You may not be who you are in development vs
deployed code.

<SNIP>

That is great information. Thank you.

I tried adding that code to my application, and I see the following:
Thread.CurrentPrincipal.Identity.Name = ""
WindowsIdentity.GetCurrent().Name = "SOMEDOMAIN\\jholder"

The windows identity is what it should be. Is the thread identity
something to worry about?

Given that the windows identity is coming back as the correct user, I
am a little perplexed why the file reads are failing.

Thank you,
John Holder

 

[trs-ggcsea]

The issue has nothing to do with C# or .NET. The simple story is that you
don't have the rights on the target machine to access "privatefile.txt". You
either need to impersonate someone who does have those rights, or otherwise
pass the credentials of someone who has the rights before connecting to the

<SNIP>

Robert,

I apologize, in my original post I neglected to mention that my domain
user does have the rights to read the file. See my post on that here:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/1ed45cea9186668c

Thank you,
John

 

[sloan]

I wouldn't get hung up on the Thread.Identity thing. I was just throwing
that in there.

If you're identity is correct, then I don't know.
Try doing something more basic than reading the file.



private string GetSafeLocalFileName(string inputFileName)
{
string returnValue;
if ((inputFileName.IndexOf("\\")) > 0) {
return inputFileName;
} else {
returnValue = System.Environment.CurrentDirectory + "\\" + inputFileName;
}
return returnValue;
}

private void DoSomething(string inputFileName)
{
try {
string filename = this.GetSafeLocalFileName(inputFileName);
if (File.Exists(filename)) {
FileInfo fi = new FileInfo(filename);
Console.Writeline(fi.Length);
}
} finally {
}
}

Try to see if it EXISTS

System.IO has those methods I think.

 

[Robert Speck]

The issue has nothing to do with C# or .NET. The simple story is that you

<SNIP>

Robert,

I apologize, in my original post I neglected to mention that my domain
user does have the rights to read the file. See my post on that here:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/1ed45cea9186668c

That being the case, then based on the constructor you're using, you're
attempting to acquire both read *and* write access (according to a quick
scan of the docs). That should raise a red flag right there (you probably
don't have write access). Try using one of the other constructors and
request read-only.

 

[trs-ggcsea]

<SNIP>

<SNIP>

Yes. Once again thank you for helping me through this. I was using
the .NET FTPClient library, and changing the following line in the :

FileStream fs = new FileStream(localFileName,FileMode.Open);

To the following line:

FileStream fs = new FileStream(localFileName,FileMode.Open,
FileAccess.Read);

Fixed the problem. It really threw me that I had been using it on
unprotected files for some time before I ran into this issue. Thanks
everyone for all suggestions.

I think I need to possibly file a bug report with FTPClient.

Thank you,
John

 

[Kevin Spencer]

Glad you got it straightened out, and thanks for sharing your solution, for
those of us who might run across a similar confusing situation in the
future.

--

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.