467,905 Members | 1,714 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,905 developers. It's quick & easy.

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

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",Fi leMode.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

Sep 8 '06 #1
  • viewed: 53661
Share:
11 Replies
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.

<tr********@simulakrum.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
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",Fi leMode.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

Sep 8 '06 #2

Kevin Spencer wrote:
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

Sep 8 '06 #3

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.

<tr********@simulakrum.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...
>
Kevin Spencer wrote:
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

Sep 8 '06 #4
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",Fi leMode.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.
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)
Sep 8 '06 #5
sloan wrote:
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

Sep 8 '06 #6
<SNIP>
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/micro...d45cea9186668c

Thank you,
John

Sep 8 '06 #7

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.

<tr********@simulakrum.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...
sloan wrote:
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

Sep 8 '06 #8
>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/micro...d45cea9186668c
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.
Sep 8 '06 #9

sloan wrote:
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.
<SNIP>

sloan,

Thanks for continuing to throw out suggestions on this thing.

It is most interesting. File.Exists() returns true for the filename
that has restrictive read permissions. If I change the filename to
another name in the same directory that does not exist, File.Exists()
returns false. So at least File.Exists() is working as expected. And
actually, that gave me an idea. Isn't there another stream class that
is read only?

Sep 8 '06 #10

trs-ggc...@simulakrum.com wrote:
sloan wrote:
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.
<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

Sep 8 '06 #11
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.

<tr********@simulakrum.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...
>
trs-ggc...@simulakrum.com wrote:
>sloan wrote:
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.
<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

Sep 9 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Dave Y | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.