issetugid() y el problema de la portabilidad de variables de entorno en programas privilegiados

Determinar si un proceso obtuvo privilegios al inicio es esencial para que las bibliotecas traten como no fiables las variables de entorno. OpenBSD introdujo en 1996 la llamada al sistema issetugid(2), pensada para que las librerías detectasen si la aplicación fue ejecutada con los bits set-uid o set-gid y, en ese caso, evitar confiar en valores como los devueltos por getenv(). Solaris/Illumos adoptaron esas mismas semánticas; FreeBSD, NetBSD, OS X y DragonFly copiaron la función, pero alteraron su comportamiento: marcaron el proceso como "contaminado" no solo si ganóprivilegios en execve(), sino también si llamó a setuid()/setgid() tras el arranque. Esta diferencia, posiblemente originada por un malentendido, provoca que utilidades administrativas ejecutadas como root y que solo pierden privilegios (sshd con KRB5_CONFIG o httpd con KRB5_KTNAME) ignoren sus variables de entorno, lo cual rompe el comportamiento esperado. En GNU/Linux existe un mecanismo equivalente, getauxval(AT_SECURE), que comparte la semántica original de OpenBSD. Algunas plataformas ya ofrecen secure_getenv(), que devuelve NULL cuando issetugid() o getauxval(AT_SECURE) detectanprivilegiosadquiridos. Sin embargo, la portabilidad eslabonada: glibc antiguo no asigna errno en getauxval(), FreeBSD solo expone los tipos auxiliares en modo de compatibilidad Linux, Illumos, NetBSD y OS X carecen de getauxval() (aunque exponen /proc/self/auxv) y getauxval() no puede estandarizarse porque convierte punteros a long. Por todo ello, implementar secure_getenv() de forma fiable requiere una larga cadena de directivas de preprocesador que pruebe issetugid(), getauxval(AT_SECURE) o, en último extremo, compare getuid()/geteuid() y getgid()/getegid(). El artículo concluye que urge adoptar semántica única y anima a Heimdal y MIT Kerberos a rechazar automáticamente entornos contaminados para no depender de inicializadores explícitos en GSS-API.