El extraño caso del crontab no permitido

Sucede que un usuario fulano no podía editar el crontab a pesar de tener los debidos permisos de grupo y las debidas configuraciones en cron.allow y cron.deny.

La cosa es que para debuggear este problema al ejecutar un crontab desde usuario se puede echar mano de la herramienta truss para ver que archivos se abren, leen, etc. Algo así:

# truss crontab -l 2> /tmp/foo

# grep "(\"/" /tmp/foo | grep open

kopen("/unix", O_RDONLY|O_LARGEFILE)            = 3
kopen("/usr/lib/security/methods.cfg", O_RDONLY) = 3
kopen("/etc/passwd", O_RDONLY)                  = 3
kopen("/etc/security/passwd", O_RDONLY)         = 4
kopen("/etc/security/login.cfg.idx", O_RDONLY)  = -1
kopen("/etc/security/login.cfg", O_RDONLY)      = 5
kopen("/etc/security/login.cfg", O_RDONLY)      = 5
kopen("/etc/security/login.cfg", O_RDONLY)      = 5
kopen("/etc/passwd.id.idx", O_RDONLY)           = -1
kopen("/etc/passwd", O_RDONLY)                  = 5
kopen("/etc/passwd", O_RDONLY)                  = 5
kopen("/etc/security/user.idx", O_RDONLY)       = -1
kopen("/etc/security/user", O_RDONLY)           = 3
kopen("/etc/security/user", O_RDONLY)           = 3
kopen("/etc/security/user", O_RDONLY)           = 3
kopen("/var/adm/cron/cron.deny", O_RDONLY)      = 3
kopen("/var/spool/cron/crontabs", O_RDONLY)     = 3

¡Queobo! De ahí sacan mas pistas del problema. A la Sherlock Holmes.