Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
El Fri, 09 Oct 2015 07:08:31 -0430, Frederit Mogollon escribió:
> Buenas compañeros de la lista.
>
> En esta ocasión les comentaré sobre un problema inicial con
> cron/crontab, pero que ahora creo se trata de actualización. Es un poco
> largo, así que por partes.
(...)
> La lista de repositorios es:
(...)
> deb http://http.debian.net/debian wheezy-backports main contrib
Yo le tengo mucho respeto a los backports porque a menudo instalan/
actualizan paquetes que no siempre esperas, generalmente bibliotecas y
generalmente también por dependencias, lo cual es esperable pero no
siempre deseable.
Mi política con los paquetes/repositorios de los backports es dejarlos
desactivados y usarlos sólo de manera premeditada, es decir, si quiero
instalar un paquete lo hago manualmente con "apt-get -t wheezy-backports
install [paquete]" y así me evito disgustos.
(...)
> Al intentar modificar la tarea de ejecución de clamav desde crontab,
> con las órdenes
>
> ----------------------
> $ crontab -l
¿Te muestra el crontab del usuario?
> $ crontab -e
> ------------------------
>
> obtuve la siguiente respuesta:
>
> ------------------------------------------------------------------
> $ crontab/tesistas: fdopen: Permiso denegado
> ---------------------------------------------------------------------
(...)
Comprueba los permisos/propietarios del directorio de tareas de tu
usuario:
ls -la /var/spool/cron/crontabs/
No veo la forma en que un escaneo de clamav altere los permisos de los
archivos, creo que no lo hace al menos de manera predeterminada y en caso
de cambiarlos sin haberle dicho expresamente que lo haga se trataría de
un bug muy serio. Lo que sí podría hacer es mover archivos a una
cuarentena pero como digo, hasta donde sé hay que configurarlo para que
eso suceda.
> Supuse que tras un cambio mayor en una de las actualizaciones, se alteró
> alguna configuración que conllevó a la pérdida de permisos por parte del
> usuario normal. Al intentar reasignar al usuario al grupo crontab, con
> la línea:
>
> -----------------------------------------------
> $ usermod -aG crontab tesistas
> ----------------------------------------------
>
> obtuve la misma respuesta de permiso denegado.
Eso de añadir tu usuario al grupo crontab no debería ser necesario :-?
> Eventualmente, descubrí que al intentar apagar o reiniciar el ordenador,
> era redirigido a la pantalla de inicio de SLiM,
> solicitando el login y password, como normalmente ocurre al cerrar
> sesión.
>
> Al intentarlo desde terminal de usuario y de root, obtuve respuestas
> similares:
>
> ------------------------------------------------------------------------
> # shutdown -h now
> bash: /usr/local/bin/shutdown: Permiso denegado
>
> ------------------------------------------------------------------------
(...)
¿Y esa ruta? :-?
root@stt008:~# whereis shutdown
shutdown: /sbin/shutdown /usr/share/man/man8/shutdown.8.gz
> En este punto pensé que el problema radicaba en la última actualización
> del kernel desde backports, por lo que opté por el reinicio forzado
> desde el hardware, e ingresé mediante el kernel
> linux-image-3.2.0-4-686-pae.
(...)
El kernel no suele hacer esas maldades de tocar los permisos, cuando te
toca las narices usa otros "métodos".
> Al realizar pruebas tanto con crontab como con el apagado, similares a
> las anteriores, obtuve las mismas respuestas de "permiso denegado",
> lo que obviamente descarta el kernel como fuente de problema.
(...)
> Estoy revisando la lista de cambios en la novena actualización de Debian
> Wheezy:
>
> Updated Debian 7: 7.9 released
> https://www.debian.org/News/2015/2015090502
Yo estoy con la misma versión pero no he tenido ese problema (eso sí, no
tengo el repo de backports habilitado y uso el kernel predeterminado)
sm01@stt008:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.9 (wheezy)
Release: 7.9
Codename: wheezy
> Se agradece si han leído hasta aquí. Cualquier idea en pro de ayudar,
> será bienvenida.
Desde luego parece un problema de permisos, vete revisando los registros
(/var/log/syslog) por si vieras algo raro y comprueba a ver cuántos
paquetes de los backports tienes instalados.
Saludos,
--
Camaleón
Reply to: