[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización



El Sat, 10 Oct 2015 10:18:07 -0430, Frederit Mogollon escribió:

(...)

>> 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
                    ^^^^

Aquí hay algo raro, mira:

root@stt008:~# ls -l /var/spool/cron/
total 0
drwxrwx--T 2 daemon daemon  72 jun  1  2013 atjobs
drwxrwx--T 2 daemon daemon  48 jun  9  2012 atspool
drwx-wx--T 2 root   crontab 48 jul  3  2012 crontabs

El grupo del directorio "crontabs" es root en tu caso y "crontab" en el 
mío (el comando lo he ejecutado desde Wheezy pero en mi testing de 
pruebas los propietarios se mantienen como en Wheezy). 

El resto de directorios también tienen los propietarios alterados.

>> 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:

(...)

> 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?

Obviamente algo ha pasado con los permisos pero no sé qué puede haberlo 
generado salvo un cambio manual. Puedes intentar reconfigurar el paquete 
con "dpkg-reconfigure cron" a ver si es capaz de arreglarlo 
automáticamente.

>> 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.

No sólo lo leí sino que ya te respondí a ese mensaje ;-)

Saludos,

-- 
Camaleón


Reply to: