El servicio cron posee un mecanismo para controlar que los usuarios creen sus propios crontab como se muestra en la siguiente tabla:
/etc/cron.allow |
/etc/cron.deny |
Resultado |
|---|---|---|
| No existe | No existe | Solamente root |
| Existe | Existe | Solamente usuarios en cron.allow |
| Existe | No existe | Solamente usuarios en cron.allow |
| No Existe | Existe | Todos menos usuarios en cron.deny |
Supongamos el siguiente escenario: un usuario está listado en ambos listados. De acuerdo a la tabla ese usuario podrá trabajar con crontabs. En realidad, ese depende de otros factores, consideremos el siguiente caso:
# ls -l /etc/cron.{allow,deny}
-rw-r-----. 1 root root 7 Apr 17 19:44 /etc/cron.allow
-rw-r-----. 1 root crontab 7 Apr 17 19:34 /etc/cron.deny
El archivo /etc/cron.allow no tiene permiso de lectura para otros, de manera que un usuario común no podrá usar el comando crontab. En dicho caso, será necesario o bien cambiar el grupo dueño del archivo o agregar permiso de lectura para el resto del mundo.
Este ejemplo puede parecer un tanto obvio: en general en Linux los archivos se crean automáticamente con permiso de lectura para otros.
Sin embargo, hay otras situaciones un poco más complicadas. Por ejemplo, consideremos el viejo servicio atd. Dicho servicio usa un esquema de accesos similar a cron. Podemos usar la misma tabla de arriba y aplicarla para at.
Pronto nos encontramos con ciertas sutilezas, vamos ahora a este ejemplo:
# ls -l /etc/at.*
-rw-r-----. 1 root daemon 151 Apr 17 19:22 /etc/at.deny
Supongamos que alguien de manera desprevenida, copia el archivo /etc/at.deny en /etc/at.allow y agrega al usuario distinto de root al listado de aquél último archivo.
El usuario agregado no tendrá permisos para usar at. Esto se debe que el arhcivo /etc/at.allow no cumple con alguna de las dos condiciones:
- Tener permiso de lectura para otros.
- El dueño del archivo no es daemon.
A veces, descubrir este error no es tan obvio, por ejemplo, si probamos con el comando strace, vemos lo siquiente:
