[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Condor-users] Window stations and execute machine environment




I am using licensed software with Condor on windows OS (XP and 7) and I believe there are several things going on that are causing the software to not work. My question is whether someone can tell me exactly how Condor executes jobs on Windows, whether the different universes run differently, and how Condor runs differently depending on whether Run_As_Onwer or Load_Profile is used in the submit files. I understand the differences between Run_As_Onwer and Load_Profile (Condor 7.4 documentation--Section 6.2.7), but what is not clear is the environment of the jobs run in Condor. According to the Condor documentation, Condor jobs (1) create a run account on the machine using “condor-reuse-slotX” if the job is not run with Run_As_Onwer, (2) create a temporary working directory on execute machine “$(EXECUTE)\dir_XXX”, and (3) creates a non-visible window station and desktop. In tasks (2) and (3) permissions are set up so the Condor process has write access to the directory and desktop.

The software I am testing with Condor, does not require access to the user’s registry. However, I am finding that not all objects that I create from their libraries work under Run_As_Owner and Load_Profile and therefore there appears to be inconsistencies with requirements that utilize different functions of the program. This software is extremely large and difficult to exhaustively test, which is why I would like more information about Condor.

I would like to know exactly how Condor creates the window station. For example, does Condor use a non-interactive process that starts under Local System in the Service-0x0-3e7$ windows station and tied to the local system or does it start a process under the users credentials which uses its own windows station where the latter is not tied to the LocalSystem. I by no means have a lot of experience with this. The vender is basically not able to duplicate the inability to create objects and run processes in a window station, which runs either as local system or as the user.

The discretionary access control list (DACL) for the window station and desktop includes the following access rights (http://msdn.microsoft.com/en-us/library/ms687096%28VS.85%29.aspx):

Window Station:
WINSTA_ACCESSCLIPBOARD
WINSTA_ACCESSGLOBALATOMS
WINSTA_CREATEDESKTOP
WINSTA_EXITWINDOWS
WINSTA_READATTRIBUTES
STANDARD_RIGHTS_REQUIRED

Desktop:
DESKTOP_CREATEMENU
DESKTOP_CREATEWINDOW
DESKTOP_ENUMERATE
DESKTOP_HOOKCONTROL
DESKTOP_READOBJECTS
DESKTOP_WRITEOBJECTS
STANDARD_RIGHTS_REQUIRED
 

A process can use the CreateWindowStation function to create a new window station, and the CreateDesktop or CreateDesktopEx. A process automatically establishes a connection to a window station and desktop when it first calls a USER32 or GDI32 function (other than the window station and desktop functions). The system determines the window station to which a process connects according to the following rules:

1.        If the process has called the SetProcessWindowStation function, it connects to the window station specified in that call.

2.        If the process did not call SetProcessWindowStation, it connects to the window station inherited from the parent process.

3.        If the process did not call SetProcessWindowStation and did not inherit a window station, the system attempts to open for MAXIMUM_ALLOWED access and connect to a window station as follows:

o        If a window station name was specified in the lpDesktop member of the STARTUPINFO structure that was used when the process was created, the process connects to the specified window station.

o        Otherwise, if the process is running in the logon session of the interactive user, the process connects to the interactive window station.

o        If the process is running in a noninteractive logon session, the window station name is formed based on the logon session identifier and an attempt is made to open that window station. If the open operation fails because this window station does not exist, the system tries to create the window station and a default desktop.

Additionally numerous settings exist for setting the security descriptor for a window station object which vary depending on the object used to for accessing a window station (http://msdn.microsoft.com/en-us/library/ms687391%28v=VS.85%29.aspx).

Thank you for the assistance,
Mike