Starting a new process, which has the same security permissions and the parent.

[Phil Mc]

Say for example you have a application running on a windows 2003 server
(that is on server, not from). This application needs to start child
applications (must be stand alone console applications), but these
child applications must have the same security privileges as the parent
starting them.

I have created a scheduling app (which will be started by autosys job),
which must start child apps when certain criteria are met. The
scheduling application has file IO permissions and works fine, but the
child applications, which are started by the parent scheduler
application (also running on the server), cause security exceptions.
Now if one runs the child applications directly by logging onto the
server (for testing), they cause no exceptions and behave as expected.
Note also if both applications are run locally on my development
machine, neither cause any exceptions.

Is there a way to explicitly pass across a currently running
applications security privileges to a application which it starts in a
new process. I start the new application using the following code.

try
{
// run the appropriate macro
System.Diagnostics.Process macro = new System.Diagnostics.Process();
macro.StartInfo.FileName = fp.MacroFilePathName;
macro.StartInfo.Arguments = SOME ARGS;
macro.Start();
}catch

 

[Willy Denoyette [MVP]]

Say for example you have a application running on a windows 2003 server
(that is on server, not from). This application needs to start child
applications (must be stand alone console applications), but these
child applications must have the same security privileges as the parent
starting them.

I have created a scheduling app (which will be started by autosys job),
which must start child apps when certain criteria are met. The
scheduling application has file IO permissions and works fine, but the
child applications, which are started by the parent scheduler
application (also running on the server), cause security exceptions.
Now if one runs the child applications directly by logging onto the
server (for testing), they cause no exceptions and behave as expected.
Note also if both applications are run locally on my development
machine, neither cause any exceptions.

Is there a way to explicitly pass across a currently running
applications security privileges to a application which it starts in a
new process. I start the new application using the following code.

try
{
// run the appropriate macro
System.Diagnostics.Process macro = new System.Diagnostics.Process();
macro.StartInfo.FileName = fp.MacroFilePathName;
macro.StartInfo.Arguments = SOME ARGS;
macro.Start();
}catch

A child process always inherits the security context of it's parent which
inherits from it's paren etc..
Your problem is that the parent itself has no appropriate Filesystem IO
permissions.
So, you need to run your scheduler, (autosys job? don't know what this is
though) as a user that has appropriate permission to whatever resource you
need to access. Another (the right) option is to impersonate a user with
approp. permission in your application.

Willy.

 

[Phil Mc]

Hi Willy, thanks for the comments...
Admin on this server box are very reluctant to let me impersonate a
logon account. I've looked at this already.

I am at testing stage, and am starting the parent application by
logging into the server box and running it manually. This is of course
passing my privileges to the app. The strange thing is that when this
parent app runs, it conducts all its file IO operations without any
problems (this involves creating dirs, moving files etc.), BUT when
this parent app starts these other child console applications, they are
causing the exceptions. These same applications if run directly form a
logon (as above), to the server, do not cause any problem.
It has me baffled. I was wondering can I explicitly pass on a security
context when starting the processes to run the child console
applications.
Cheers

 

[Willy Denoyette [MVP]]

Hi Willy, thanks for the comments...
Admin on this server box are very reluctant to let me impersonate a
logon account. I've looked at this already.

I am at testing stage, and am starting the parent application by
logging into the server box and running it manually. This is of course
passing my privileges to the app. The strange thing is that when this
parent app runs, it conducts all its file IO operations without any
problems (this involves creating dirs, moving files etc.), BUT when
this parent app starts these other child console applications, they are
causing the exceptions. These same applications if run directly form a
logon (as above), to the server, do not cause any problem.
It has me baffled. I was wondering can I explicitly pass on a security
context when starting the processes to run the child console
applications.
Cheers

Phil,

I would suggest you:
- turn-on security auditing for the file objects, and
- set the auditing policy (Local Policy Settings) to Audit object access
(enable both failure and success).
When done, you can try to run the application (both failing and working) and
watch the eventlog (security log) messages for both failures and success,
check who's the IO requestor and it's IO privileges.
If the identity of the IO requestor is not the same for both runs, it would
mean that one of the programs in the child - parent chain is impersonating.
Normaly the IO requestor should be the same as the account of the current
logon session.

Willy.

 

[Phil Mc]

Phil,

I would suggest you:
- turn-on security auditing for the file objects, and
- set the auditing policy (Local Policy Settings) to Audit object access
(enable both failure and success).
When done, you can try to run the application (both failing and working) and
watch the eventlog (security log) messages for both failures and success,
check who's the IO requestor and it's IO privileges.
If the identity of the IO requestor is not the same for both runs, it would
mean that one of the programs in the child - parent chain is impersonating.
Normaly the IO requestor should be the same as the account of the current
logon session.

Willy.

Willy, thanks and that makes a lot of sence, Ill have a shot at that in
the morning on a freash head, thanks again