{subsection: What UID does HTCondor run as?}
-In general, a HTCondor user and group should be created on a machine before it is added to a HTCondor pool. While the HTCondor user can have the same UID and GID on all the machines in the pool, it does not need for this to be true. In environments where there is a common condor user across many machines, the home directory of the condor account must be on the local disk of each one, not shared by more than one machine. This home directory holds HTCondor's configuration files and three subdirectories called "spool", "execute" and "log". The spool directory holds the queue of jobs that are currently submitted, all the checkpoints and binaries of jobs that have been submitted but have not yet completed, and a history file containing information about all of the completed jobs. The log directory holds log files for all the daemons. The execute directory will be discussed below. All of these directories are owned by user and group condor, and are group-writable. Many HTCondor tools are binaries that set their GID (setgid) to group condor, so that any user on the machine can manipulate the job queue.
+In general, a condor user and group should be created on a machine before it is added to a HTCondor pool. While the condor user can have the same UID and GID on all the machines in the pool, it does not need for this to be true. In environments where there is a common condor user across many machines, the home directory of the condor account must be on the local disk of each one, not shared by more than one machine. This home directory holds HTCondor's configuration files and three subdirectories called "spool", "execute" and "log". The spool directory holds the queue of jobs that are currently submitted, all the checkpoints and binaries of jobs that have been submitted but have not yet completed, and a history file containing information about all of the completed jobs. The log directory holds log files for all the daemons. The execute directory will be discussed below. All of these directories are owned by user and group condor, and are group-writable. Many HTCondor tools are binaries that set their GID (setgid) to group condor, so that any user on the machine can manipulate the job queue.
HTCondor works most smoothly when it is started up as root. The daemons then all have the ability to switch their real UIDs and effective UIDs at will. When this happens, all the daemons run as root, but normally leave their effective UID and GID to be those of user and group condor. This allows access to the log files without changing their ownership. It also allows access to these files when the condor home directory resides on an NFS server, since root can not normally access NFS files. Before the shadow is created, the schedd switches back to root, so that it can start up the shadow with the UID of the user who submitted the job. Since the shadow runs as the owner of the job, all remote system calls are performed under his or her UID and GID. This ensures that as the HTCondor job executes, it can only access files that its owner could access if it were running locally, without HTCondor. On the executing machine, the starter starts off the job running as user nobody, to help ensure that it can not access any local resources or do any harm. On certain platforms, some daemons must also switch to root to get information about the machine from the kernel, such as how much memory and swap space are in use. A few platforms actually require another HTCondor daemon, the keyboard daemon, "kbdd". The kbdd queries the X server on its machine, to find out information about mouse and keyboard activity under X Windows. This daemon generally must run as root to perform this task.
