No siempre es posible que los demonios sean ejecutados por el super-usuario, por ejemplo cuando un único recurso configurado con Condor es compartido por varios usuarios. En este caso, por cuestiones de seguridad, puede efectuarse una instalación
donde sólo puedan emitirse trabajos por un único usuario, no habiendo necesidad de que los demonios se ejecuten por el super-usuario.
A continuación se detallan aspectos de Condor considerando los casos en los que los demonios se ejecutan por el super-usuario y donde no se ejecutan por el super-usuario.
Condor_startd: Si se está configurando un nodo para que ejecute trabajos en Condor,
este demonio debe ser iniciado por el usuario root, de lo contrario los usuarios podrán iniciar, suspender, desalojar y/o eliminar los trabajos de Condor a su voluntad. De otra manera, las políticas las define el super-usuario. Si este demonio se ejecuta por el super-usuario, los trabajos se ejecutarán con un UID diferente, que puede ser el del usuario que emitió el trabajo o bajo el usuario nobody, dependiendo del valor de la variable UID_DOMAIN.
Como consecuencia de lo anterior, el trabajo que se está ejecutando no podrá dañar a los demonios de Condor.
Si los demonios no son inicializados por el super-usuario, todos los procesos iniciados por Condor, incluido el trabajo del usuario, se ejecutarán con el mismo UID, ya que el UID sólo puede ser modificado por el super-usuario.
Esto implica importantes riesgos, ya que el trabajo del usuario podría eliminar al demonio condor_startd y al demonio condor_starter ni bien se inicializa, y de esta manera evitaría ser suspendido o desalojado del recurso donde esta ejecutándose al retornar su propietario. Debido a ello, el demonio condor_startd siempre debe ser inicializado por el super-usuario.
Cabe destacar que si no se es super-usuario, no podrá accederse a cierta información del sistema, por lo que en estos casos el demonio condor_startd debe llamar a otros programas para obtener esa información. Esto resulta ser mucho menos eficiente que acceder a esta información directamente desde el kernel, que es lo que se hace cuando se ejecutan los procesos como super-usuario.
Si por alguna razón el super-usuario no puede ejecutar todos los demonios, al menos debería considerarse instalar el demonio condor_startd con el UID de root.
Condor_schedd: El mayor problema al ejecutar el demonio condor_schedd sin
privilegios de super-usuario es que el demonio condor_shadow que es creado por el demonio condor_schedd, tendrá el mismo UID de este último lo cual significa que los usuarios que emitan sus trabajos deberán permitir acceso de escritura y lectura a los archivos y directorios, para el usuario o grupo condor, o cualquiera sea el usuario bajo el que este ejecutándose el demonio condor_schedd.
Condor_master: Este demonio inicia al demonio condor_startd y al demonio
condor_schedd. Para que ambos se ejecuten con privilegios de super-usuario, el
demonio condor_master debe ser iniciado por el super-usuario.
Condor_negotiator y Condor_collector: No hay necesidad de que estos demonios
sean ejecutados por el super-usuario.
Condor_kbdd: La importancia de este demonio radica en que a través de él, el
Si se decide ejecutar los demonios de Condor sin privilegios de super-usuario, puede elegirse cualquier usuario, aunque lo habitual es elegir al usuario condor. Esto simplifica la configuración de Condor, ya que este usuario, por defecto, buscará los archivos de configuración en el directorio del usuario de condor.
En caso de no seleccionarse este usuario, el administrador del sistema deberá asegurarse de que Condor encuentre sus archivos de configuración necesarios.
Si los trabajos son emitidos con un usuario diferente del que está ejecutando los demonios de Condor, entonces deberá tenerse la precaución de que estos usuarios sólo puedan acceder a los archivos de su propiedad.
En la práctica suele suceder que los directorios donde se almacena la salida de los trabajos de Condor tienen permisos de escritura para todos los usuarios. Esto significa un riesgo importante en la seguridad, en el sentido de que cualquier usuario que utilice el recurso desde el cual se emitió el trabajo, podrá alterar los datos o eliminarlos. Una configuración de estas características es aceptable solo en ambientes donde los usuarios confían entre sí.
Normalmente, los usuarios sin permisos de super-usuario que necesitan utilizar Condor en sus máquinas, crean con su cuenta de usuario, un directorio home llamado condor e inician los demonios con el usuario propio.
Como en el caso donde los demonios se ejecutan con el usuario condor, no hay posibilidad de que estos cambien su UID o GID. Los demonios se ejecutan con el UID y el GID del usuario que los inició.
En un nodo desde el cual un usuario emitió un trabajo, el demonio condor_shadow se ejecutará bajo ese mismo usuario, pero si hay otros usuarios utilizando Condor en ese recurso, los demonios condor_shadow de esos otros usuarios se ejecutarán con el UID del usuario que haya iniciado los demonios.
Esto también implica un riesgo de seguridad, ya que los trabajos Condor de los otros usuarios tendrán acceso a todos los archivos y directorios del usuario que inició esos demonios.
En las instalaciones donde no existe confianza entre los usuarios, es aconsejable configurar una cuenta cuyo propietario y grupo sea condor, o permitir que cada usuario configure su propia instalación personal de Condor para emisión de trabajos.
Cuando un nodo es el sitio de ejecución para los trabajos Condor, este trabajo se ejecuta con el UID del usuario que inició al demonio condor_startd. Esto también implica un riesgo de seguridad, por lo que no se recomienda iniciar los demonios en el sitio de ejecución de los trabajos como un usuario regular. Se recomienda iniciar los demonios con privilegios de superusuario o bajo el usuario condor, que sólo existe para ejecutar trabajos Condor.