A program whose path is not readable cannot make any connection
Hello,
We have an issue with file permissions. If we have a path like
N:\applications\myapp\app.exe
where N: is some network drive
and the user cannot list N:\applications (becuase we want to keep the list of applications private), but can execute app.exe, the application can start, but if if attempts to make a network connection it fails. This used to work fine in Windows XP, but is
failing with Windows 7, and precluding our migration.
Why? What policy could we use?
January 25th, 2011 3:24pm
This is exactly the same problem we are having
Free Windows Admin Tool Kit Click here and download it now
January 25th, 2011 6:15pm
Hi,
Thanks for posting in Microsoft TechNet Forum.
What is the result when you granted the user read access on \\
N:\applications? Have you resolved this issue?
Alex Zhao
TechNet
Subscriber Support
in forum.
If you have any feedback on our support, please contact
tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
January 26th, 2011 6:52am
If we grant read access to the directory, then applications work. But this solution is not acceptable for us. The information that we manage is quite confidential. Users should know nothing about the names of available applications, except those that they
are authorized to use.
Free Windows Admin Tool Kit Click here and download it now
January 26th, 2011 10:57am
Hello ti2009,
Thank you for your update.
I am currently looking into this issue and will give you an update as soon as possible.
Thank you for your understanding and support.
Alex Zhao
TechNet
Subscriber Support in forum.
If you have any feedback on our support, please contact
tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
January 30th, 2011 10:40pm
Thanks, we look forward having a solution to this problem.
Free Windows Admin Tool Kit Click here and download it now
January 31st, 2011 5:50pm
Is there any progress about this issue? Is it a bug? A confirmed feature?
February 4th, 2011 9:00pm
Are there any news?
Free Windows Admin Tool Kit Click here and download it now
February 14th, 2011 10:48am
Hello,
The application here is running in the context of the user as far as I can understand from the prefious information. I do not know why it was working in XP. There are security differences between XP and Windows 7 that may be preventing the application
from accessing data on a network location that it cannot read. There may be something coded within the application that is incompatible with the security features of Windows 7.
At this point I would recommend opening a support case with Microsoft. If you are a premier customer I would do this through your TAM. If not I use the following link -
http://support.microsoft.com/?Open&src=hot&docid=2003082012355706&nsf=nav.nsf&view=docid&seg=hho&lg=en&ct=us?Open&src=hot&docid=2003082012355706&nsf=nav.nsf&view=docid&seg=hho&lg=en&ct=us
February 14th, 2011 4:38pm
This issue can be reproduced with any application that opens a network connection, like netcat. Just place netcat in a network folder with execute permission, but without read permission. Netcat executes, it can show help, but if it attempts to connect,
that connection fails. In a previous post, I added a
link to a simple example, with a lot of troubleshooting information. It appears that when an application opens a socket, the file \Device\Afd\Endpoint is accessed:
The file it is trying to open is "\Device\Afd\Endpoint" It returns an error code of 0xC000225 (Status Not Found). The IoStatusBlock.Information value is 0x1 (FILE_OPENED) after the call.
So where does our mysterious error 10022 come from? When NtCreateFile fails, there's another call to NtStatusToSocketError with 0xC000225 as the argument. This function is the one that returns 10022 (WSAEINVAL - Invalid Argument), and in the
debugger window there's an error string
0x508-MSWSOCK> NtStatusToSocketError: unable to map 0xC0000225, returning
So, it seems to me that our process when run from this share doesn't have the correct permissions to open/create \Device\Afd\Endpoint" when running from the problem network share. I'm running as Administrator with UAC disabled, so there shouldn't
be any issues there.
Free Windows Admin Tool Kit Click here and download it now
February 15th, 2011 9:46am
Hello,
Are there any news about this issue?
February 21st, 2011 9:18am
Any news? We are still waiting?
Free Windows Admin Tool Kit Click here and download it now
March 1st, 2011 11:15am
Hello,
we need a solution to this issue. It is not normal to have a behaviour not explained by the documentation, clearly a bug, as explained above, and getting a complete silence as answer. This behaviour is not serious at all. One cannot pretent that this is
a company that we can depend on, a company that does not even bother say if this is a bug.
March 7th, 2011 12:29pm
We are still waiting for a solution.
Free Windows Admin Tool Kit Click here and download it now
March 11th, 2011 3:08pm
We are still waiting for a solution
March 21st, 2011 9:11pm
maybe some silly recommendations :
- try with a "working directory" not in N:\...but something else ?
- try to change search dll path behavior , may be it is related to the new "CWDIllegalInDllSearch" : http://support.microsoft.com/kb/2264107/en-us
Hope this help
jean-marc habyjean-marc Haby
Free Windows Admin Tool Kit Click here and download it now
March 21st, 2011 10:22pm
Sorry Jean-Marc , but this does not work.
I am trying with a working directory %USERPROFILE%. Any application that starts a network connection starts, but fails just before a network operation. I have copied nc.exe (netcat) to a share that cannot read as normal user, and when executing it
c:\> N:\applications\myapp\nc.exe www.google.com 80
Can't get socket: INVAL
nc.exe only uses system shared libraries.
March 23rd, 2011 6:26pm