CreateProcess with redirection access denied on the output pipe
IlyaK
I have a simple code running in a DLL called from MFC application.
Generally it implements the example that is shown in msdn article -
http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx.
Except I just want to create any process (say shell script). All the
process creation is done fine with no errors. However, ReadFile with
the output pipe always fails with error 5:Access is denied. Making the
same calls in a regular Win32 console application runs fine.
Please help.
-Ilya.
Kerem Gümrükcü
Hi Ilya,
when you get a ACCESS_DENIED (5) then it is pretty
clear that you miss some access rights on some functions,
files, keys, or whatever you try to access from your code.
Important would be here to know what OS you are using.
I guess its Vista or Windows 7, since there you have several
restrictions like UIPI (User Interface Privilege Isolation), just
to name one. It also could be some problem with the shell
script itself, there are many possible things that could break
your application. Good would be if you could please tell what
OS you are running on, what usercontext your are executing
the code and try to execute another stuff (code,exe,dll,etc.)
from that and where does the stuff reside. Are you running
on terminal, local, etc,..whatever you feel is important, tell us
please,...and do not forget to show some code,...!
Regards
Kerem
--
-----------------------
Beste Gr�sse / Best regards / Votre bien devoue
Kerem G�mr�kc�
Latest Project: http://www.pro-it-education.de/software/deviceremover
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"IlyaK" <katsn...@gmail.com> schrieb im Newsbeitrag
news:ec79fdee-09b8-460d...@u36g2000prn.googlegroups.com...
IlyaK
1. It is WinXP SP3.
2. I have an MFC GUI that calls a function in a DLL, this function is
supposed to execute that script. The script is just like this: "C:
\cygwin\bin\python.exe C:\dev\main\src_dev2\tools\test.py"
3. The strange this is that I have a small console app with the same
code from the example and it runs fine.
4. Everything runs local.
Thanks so much,
-Ilya.
Remy Lebeau
"IlyaK" <katsn...@gmail.com> wrote in message news:ec79fdee-09b8-460d...@u36g2000prn.googlegroups.com...
> I have a simple code running in a DLL called from MFC application.
> Generally it implements the example that is shown in msdn article -
> http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx.
That code does not take security rights into account. Try providing an actual SECURITY_DESCRIPTOR structure in the lpPipeAttributes parameter of CreatePipe() to allow unrestricted access to the pipe in both processes.
> Except I just want to create any process (say shell script). All the
> process creation is done fine with no errors. However, ReadFile
> with the output pipe always fails with error 5:Access is denied.
Sounds like the spawned process is probably running in a different security context than the app that is using the DLL.
> Making the same calls in a regular Win32 console application runs fine.
A console app runs in the security context of the console that it i running in. Of a console app spawns another console app within the same console, then they are going to be in the same security context.
--
Remy Lebeau (TeamB)
IlyaK
I believe you are right about the cause of the problem - incorrect
SECURITY_DESCRIPTOR structure in the lpPipeAttributes parameter of
CreatePipe(). The sad thing is that in Windows setting this security
stuff is less than straightforward. At least based on what I have read
so far.
Do you by any chance know of a good example?
Thank you,
-Ilya.
Remy Lebeau
> I believe you are right about the cause of the problem - incorrect
> SECURITY_DESCRIPTOR structure in the lpPipeAttributes
> parameter of CreatePipe(). The sad thing is that in Windows setting
> this security stuff is less than straightforward. At least based on
> what I have read so far.
Security is not supposed to be easy.
> Do you by any chance know of a good example?
SECURITY_DESCRIPTOR saDesc;
InitializeSecurityDescriptor(&saDesc, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(&saDesc, TRUE, NULL, FALSE);
SECURITY_ATTRIBUTES saAttr;
saAttr.nLength = sizeof(SECURITY_ATTRIBUTES);
saAttr.bInheritHandle = TRUE;
saAttr.lpSecurityDescriptor = &saDesc;
... = CreatePipe(..., &saAttr, ...);
--
Remy Lebeau (TeamB)
m
though often effective, is not secure at all, but is definitely not easy.
One way that may help you think about what ACEs are appropriate is to think
of the thread's token as an extension of its execution context and to think
about what programs and parts of programs will access (open not IO) this
secured object. Once the list of places that access the object is known,
then based on who they run as, it should be obvious how to construct a SD
that will allow enough access - the real trick is to make one that will deny
the wrong access.
Remember that the object itself, in your case a pipe end-point, exists in
the OS kernel, and each handle is a reference to it with a set of
access-rights attached. There can also be many handles to the same object
with different access rights opened by the same process. When you call an
API like ReadFile, it will check that the handle that you passed in was
opened with enough access (read data etc.) on the object, but it will not
check if the caller's security context would allow such access based on the
object's security descriptor - that would make the whole OS far too slow to
use usable - and since handles have process global scope, and inheritance is
a special kind of handle duplication, it shouldn't be too hard to track down
the places of interest in your code.
"Remy Lebeau" <no....@no.spam.com> wrote in message
news:ucL5hv6e...@TK2MSFTNGP02.phx.gbl...