Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
>> root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/
>> total 12 drwx-wx--T 2 root root 4096 jul 10 01:00 .
>> drwxr-xr-x 5 root root 4096 abr 17 16:01 ..
>> -rw------- 1 tesistas crontab 1630 jul 10 01:00 tesistas
>
> Parece correcto. Sube un nivel más para ver si los permisos/propietarios
> siguen bien:
>
> ls -la /var/spool/cron/
>
--------------------------------------------------------------------------
tesistas@Tesistas:~$ ls -la /var/spool/cron/
total 20
drwxr-xr-x 5 root root 4096 abr 17 16:01 .
drwxr-xr-x 4 root root 4096 jul 18 14:52 ..
drwxrwx--T 2 root root 4096 abr 17 16:03 atjobs
drwxrwx--T 2 root root 4096 oct 3 2014 atspool
drwx-wx--T 2 root root 4096 jul 10 01:00 crontabs
-----------------------------------------------------------------------------
> Y revisa también lo que comentan en esta página, más que nada porque el
> mensaje que recibe el usuario parece el mismo que recibes tú:
>
> crontab listing or editing results in fopen: permission denied
> http://serverfault.com/questions/619296/crontab-listing-or-editing-
> results-in-fopen-permission-denied
>
Revisé el link que dejaste, y efectivamente puedo editar el crontab de
mi usuario accediendo como superusuario, sin modificar permisos:
-------------------------------------------------------------------------------------
tesistas@Tesistas:~$ sudo crontab -u tesistas -e
0 0 13 * * 4 /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril
/home/tesistas/Descargas
-------------------------------------------------------------------------------------
Aunque lo extraño es que antes podía hacerlo sin sudo. Además, creo
que el enfoque no es tanto sobre cron/crontab, sino en ¿por qué
carrizo se vieron afectados los permisos si no los toqueteé? y ¿por
qué no me deja apagar/reiniciar el equipo, devolviéndome al inicio de
sesión, aún como superusuario?
>> Aquí si es falta mía en agregar que para apagar el ordenador desde el
>> usuario normal sin privilegios de root (es un ordenador con un solo
>> usuario -tesistas-, pero utilizado por varias personas desde la misma
>> cuenta de usuario), había creado links simbólicos de los comandos
>> /sbin/shutdown, /sbin/reboot y /sbin/halt al path del usuario tesistas.
>> Esto en nada representa un factor que contribuya al problema en debate,
>> puesto que lo había implementado ya desde hace más de año y medio, y
>> funcionaba de maravilla.
>
> Pero no es normal que no te permita apagar el equipo y que te devuelva l
> inicio de sesión, porque entiendo que has ejecutado el "shutdown -h now"
> como súperusaurio ¿no? En caso contrario, prueba como root.
>
Si, lo he intentado como root
> Bueno, es pronto para saber qué es lo que ha pasado, de momento hay
> algunos comandos que no funcionan como deberían pero de ahí a echar la
> culpa a los backports va un mundo :-)
>
> Los paquetes de los backports llevan la coletilla "-bpo" y aquí la
> mayoría (en realidad, todos menos el kernel) no la tienen, es decir, que
> no parece que el problema venga de esos paquetes.
>
Si lees mi mensaje anterior en el hilo (de fecha 10 de octubre de
2015, 2:28 a. m), te darás cuenta por qué lo digo.
Saludos
fdm
Reply to: