No usaría la palabra "concerniente", pero es algo que debes tener en cuenta. Cuando ejecuta un programa con diferentes privilegios, siempre debe tener cuidado con el entorno en el que se ejecuta el programa con privilegios diferentes.
Si el programa se ejecuta con privilegios elevados, debe tener cuidado con el entorno en el que se ejecuta: las variables de entorno son un riesgo bien conocido ( PATH
, LD_PRELOAD
, EDITOR
, ... para nombrar algunos entre muchos ).
Si el programa se ejecuta con privilegios reducidos, el entorno debe tener cuidado con las credenciales que recibe el programa. Las credenciales incluyen usuarios y grupos, pero también descriptores de archivos abiertos y cosas similares. El directorio actual cuenta como una cosa similar. En esta nota, sudo
cierra todos los descriptores de archivo excepto los estándar (0, 1, 2), mientras que (al menos en Linux) su
no los toca.
Puede ser útil pasar procesos con privilegios reducidos, como un directorio actual o descriptores de archivos. En su caso, esto permite que un programa se ejecute como usuario2 y procese los archivos en ese directorio específico, sin permitir que el programa acceda a todos los otros directorios a los que puede acceder usuario1 pero no usuario2. Un ejemplo clásico con descriptores de archivos es iniciar un proceso de servidor como root con un puerto TCP privilegiado abierto, y luego soltar privilegios antes de ejecutar la aplicación del servidor, de esa manera la aplicación puede servir a este puerto privilegiado específico pero no a otro.
Por cierto, hay otra forma en que puede surgir esta situación (un proceso no puede cambiar a su directorio actual): si los permisos del directorio cambian después de que el proceso se haya cambiado a ese directorio, eso no afectará al directorio actual del proceso.
Si esto plantea un riesgo de seguridad depende del escenario específico. Antes de cambiar los privilegios, el directorio actual es una de las cosas que deben ser saneadas, como el entorno, los descriptores de archivos, etc.