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

2015-10-11 Por tema Frederit Mogollon 
2015-10-11 11:31 GMT-04:30, Frederit Mogollon :

> Las configuraciones que había hecho para apagar/reiniciar sin
> privilegios de superusuario solo las llevé a cabo luego de una buena
> búsqueda en Google. Y todo salió bien. Y es una de las normas de la
> lista, buscar primero antes de caer a preguntar sin más... eso lo he
> aprendido desde que estoy usando Debian.
>
> Sin embargo, la duda que me embarga está planteada arriba, y no se me
> quita de la mente que algo de la última actualización tuvo que ver...
> no hay otra manera. En base a ello, estuve revisando en la Internet, y
> hasta ayer no había hallado respuesta.
>
> Seguiré intentando.
>
>
>
> Bueno, gracias a todos los que me echaron la mano. Es genial contar
> con una comunidad dispuesta a yudar. Espero más temprano que tarde,
> poder contribuir a la lista, para retribuir toda la ayuda que me han
> prestado en estos años.
>
>
> Saludos
>
> fdm
>


Ahhh... casi lo olvido. Marco este tema como [SOLUCIONADO]

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

2015-10-11 Por tema Frederit Mogollon 
Para lo sugerido por Ramses y Manolo:
Entre al modo recovery desde el GRUB2 y
- Eliminé los enlaces simbólicos /usr/local/bin/shutdown,
/usr/local/bin/halt y /usr/local/bin/reboot.
- Luego cambié al grupo root los comandos /sbin/shutdown, /sbin/halt y
/sbin/reboot.
- Por último, cambié los permisos de los tres comandos anteriores a:

# ls -l /sbin/shutdown
-rwxr-xr-x 1 tesistas root 22192 abr 27 00:48 /sbin/shutdown

# ls -l /sbin/halt
-rwxr-xr-x 1 tesistas root 13848 abr 27 00:49 /sbin/halt

# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt


Con esto, al usar el comando

# init 0

el sistema se apagó como debe ser. :)


Ya en modo gráfico, todo funciona nuevamente. Ya puedo
apagar/reiniciar usando sudo desde la terminal.


Gracias por la ayuda. Lo que no me queda claro, es que si estuve
trabajando por más de 1 año  con las opciones que había configurado
para apagar/reiniciar sin privilegios root:

¿por qué razón se alteraron los permisos de estos comandos???

Es un tema que aún debo investigar más... no me puedo quedar con esta
duda que me está carcomiendo :)





2015-10-11 10:39 GMT-04:30, Camaleón :
> El Sun, 11 Oct 2015 01:40:00 -0430, Frederit Mogollon escribió:
>

>>
>> 2). Recién instalado, se configuró el sistema para
>> apagado/reinicio/cierre de sesión sin privilegios de superusuario:
>
> (...)
>
> Creo que aquí está el lío con el cambio de ruta, usuarios, grupos,
> permisos. A mí "sudo" no me gusta, pero mira el Método 2 que usan
> en esta guía.
>
> How to allow non-super users to shutdown computer in Linux
> http://how-to.wikia.com/wiki/How_to_allow_non-super_users_to_shutdown_computer_in_Linux
>


Gracias por el link, lo revisaré...!



>>
>> Con esto me doy cuenta que mis conocimientos sobre GNU/Linux aún son muy
>> limitados. Sin embargo, el sentido común me dice que falta algo que
>> permita apagar/reiniciar el sistema.
>
> Bueno, por lo general (99%) siempre hay alguien que ha pasado por la
> misma situación antes que tú, sólo hay que buscar en Google y ver
> cómo lo resolvieron :-)
>
> Saludos,
>
> --
> Camaleón
>
>

Las configuraciones que había hecho para apagar/reiniciar sin
privilegios de superusuario solo las llevé a cabo luego de una buena
búsqueda en Google. Y todo salió bien. Y es una de las normas de la
lista, buscar primero antes de caer a preguntar sin más... eso lo he
aprendido desde que estoy usando Debian.

Sin embargo, la duda que me embarga está planteada arriba, y no se me
quita de la mente que algo de la última actualización tuvo que ver...
no hay otra manera. En base a ello, estuve revisando en la Internet, y
hasta ayer no había hallado respuesta.

Seguiré intentando.



Bueno, gracias a todos los que me echaron la mano. Es genial contar
con una comunidad dispuesta a yudar. Espero más temprano que tarde,
poder contribuir a la lista, para retribuir toda la ayuda que me han
prestado en estos años.


Saludos

fdm

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

2015-10-11 Por tema Camaleón 
El Sun, 11 Oct 2015 01:40:00 -0430, Frederit Mogollon escribió:

> Este hilo se está haciendo muy largo.
> Para no extenderme más, hago un resumen del problema y lo solucionado
> hasta ahora (por favor, leer hasta el final):

(...)

> 1). Se creó 1 cuenta de usuario normal (tesistas) para varias personas.
> 
> 2). Recién instalado, se configuró el sistema para
> apagado/reinicio/cierre de sesión sin privilegios de superusuario:

(...)

Creo que aquí está el lío con el cambio de ruta, usuarios, grupos, 
permisos. A mí "sudo" no me gusta, pero mira el Método 2 que usan 
en esta guía.

How to allow non-super users to shutdown computer in Linux
http://how-to.wikia.com/wiki/How_to_allow_non-super_users_to_shutdown_computer_in_Linux

> Situación actual:
>Aún no he podido solucionar lo de los permisos para
> apagado/reinicio. Al comprobar los permisos de los ejecutables
> /sbin/shutdown y /sbin/halt veo que el propietario y el grupo de ambos,
> tesistas y fuse, respectivamente, no tienen permisos de ejecución.

(...)

> Lo que llevo hecho:

(...)
 
> - Sigo sin poder apagar/reiniciar como usuario normal ni como
> superusuario. No tengo permisos.
> 
> 
> Con esto me doy cuenta que mis conocimientos sobre GNU/Linux aún son muy
> limitados. Sin embargo, el sentido común me dice que falta algo que
> permita apagar/reiniciar el sistema.

Bueno, por lo general (99%) siempre hay alguien que ha pasado por la 
misma situación antes que tú, sólo hay que buscar en Google y ver 
cómo lo resolvieron :-)

Saludos,

-- 
Camaleón

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

2015-10-11 Por tema Frederit Mogollon 
2015-10-11 4:40 GMT-04:30, Manolo Díaz :
> El domingo, 11 oct 2015 a las 06:10 UTC
> Frederit Mogollon escribió:
>

>
>> - Sigo sin poder apagar/reiniciar como usuario normal ni como
>> superusuario. No tengo permisos.
>
> Efectivamente, no tienes permiso de ejecución para nadie en esos dos
> ejecutables: tienes el bit setuid pero no permiso de ejecución para
> root (indicado por la S mayúscula). Por otro lado, ¿para qué cambiar el
> grupo si luego el grupo no tiene ningún permiso?
>
> ¿Has pensado en el enfoque de Ramses, dejar los permisos originales y
> utilizar sudo?
>
> --
> Manolo Díaz
>
>


Hola Ramses, Manolo I

En el sudoers sigue todo como lo especifique desde un principio.

Voy a probar con usar los permisos originales a ver que tal. Les cuento.

Como dato, añado que he estado apagando la máquina dejando presionado
el botón de encendido del case/cpu, ayer lo intenté desde una terminal
root con el comando
# init 0

y me envió a la consola tty1 con el mensaje siguiente

Debian GNU&Linux t Tesistas tty1
Tesistas login : [8700.289287] EXT4-fs (sda1): remount. Opts: (null)
INIT: no more process left in this runlevel


y allí se quedó congelada. Igual tuve que apagarla por el botón del case.

fdm

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

2015-10-11 Por tema Manolo Díaz 
El domingo, 11 oct 2015 a las 06:10 UTC
Frederit Mogollon escribió:


> Lo que llevo hecho:
> 
> 1/ Cambié los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt  al
> grupo salir:
> 
> # chgrp salir  /sbin/shutdown  /sbin/reboot   /sbin/halt
> 
> 2/ Dí permisos de ejecución a los comandos /sbin/shutdown y /sbin/halt:
> 
> # chmod u+s,o-rwx  /sbin/shutdown   /sbin/halt
> 
> 3/ Revisé el estado de los permisos para estos comandos:

[...]

> root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
> -rwSr- 1 tesistas salir 22192 abr 27 00:48 /sbin/shutdown

[...]

> root@Tesistas:/home/tesistas#  ls -l /sbin/halt
> -rwSr- 1 tesistas salir 13848 abr 27 00:49 /sbin/halt

[...]
 
> - Sigo sin poder apagar/reiniciar como usuario normal ni como
> superusuario. No tengo permisos.

Efectivamente, no tienes permiso de ejecución para nadie en esos dos
ejecutables: tienes el bit setuid pero no permiso de ejecución para
root (indicado por la S mayúscula). Por otro lado, ¿para qué cambiar el
grupo si luego el grupo no tiene ningún permiso?

¿Has pensado en el enfoque de Ramses, dejar los permisos originales y
utilizar sudo?

-- 
Manolo Díaz

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

2015-10-11 Por tema Ramses 
El 11 de octubre de 2015 08:10:00 CEST, Frederit Mogollon 
 escribió:
>Este hilo se está haciendo muy largo.
>Para no extenderme más, hago un resumen del problema y lo solucionado
>hasta ahora (por favor, leer hasta el final):
>
>Sistema: Debian Wheezy + IceWM + SpaceFM + SLiM
>Ordenador: CPU 1,7 GHz + 512 RAM + HD 13 GB
>
>Instalación: NetInstall + paquetes oficiales + paquetes propietarios +
>scripts propios y de  terceros.
>
>Propósito: General, investigación científica.
>
>Comentarios de interés para esta consulta y breve historial de la
>instalación:
>
>1). Se creó 1 cuenta de usuario normal (tesistas) para varias personas.
>
>2). Recién instalado, se configuró el sistema para
>apagado/reinicio/cierre de sesión sin privilegios de superusuario:
>
>2.1). Como root, creé un grupo llamado salir.
>2.2). El usuario fue asignado al grupo salir.
>2.3). Los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt se
>cambiaron al grupo salir.
>2.4).  Asigné permisos de lectura, escritura y ejecución para
>propietario, grupo y otros a los comandos del punto anterior.
>2.5). Creé enlaces simbólicos de /sbin/shutdown, /sbin/reboot y
>/sbin/halt hasta el directorio /usr/local/bin.
>2.6). Se editaron varias líneas del archivo /etc/sudoers de la
>siguiente forma:
> Defaults
>secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> User_AliasUSERS = tesistas
> Cmnd_AliasSHUTDOWN = /usr/local/bin/shutdown,
>/usr/local/bin/halt, /usr/local/bin/reboot
> USERSALL = NOPASSWD: SHUTDOWN
> USERSALL = NOPASSWD: /sbin/poweroff
> %sudo   ALL = (ALL:ALL) ALL
>
>3). Desde el repositorio Wheezy-backports se requirió instalar
>p11-kit-modules:i386 y pepperfalashplayer-nonfree.
>
>4). Casi un año de instalado y todo funcionaba bien. Luego, varios
>meses atrás, hice "aptitude full-upgrade" con los repositorios
>Wheezy-backports habilitados.
>
>5). Hace unos 4-5 días hice "aptitude upgrade" instalándose la
>actualización para Wheezy 7.9.
>
>
>El problema:
>   Al usar el ordenador, hace un  par de días, noté que al intentar
>apagarlo o reiniciarlo entraba de nuevo en sesión. Al intentarlo desde
>la terminal de usuario me denegaba el acceso por falta de permisos.
>Igual resultado al intentarlo como superusuario.
>   Revisando me percaté de que tampoco tenía acceso a las tareas cron
>del usuario, sin privilegios de root, cuando antes lo podía hacer sin
>problemas.
>
>Solución parcial:
>   El problema con cron se solucionó al hacer "dpkg-reconfigure cron".
>
>Situación actual:
>   Aún no he podido solucionar lo de los permisos para
>apagado/reinicio. Al comprobar los permisos de los ejecutables
>/sbin/shutdown y /sbin/halt veo que el propietario y el grupo de
>ambos, tesistas y fuse, respectivamente, no tienen permisos de
>ejecución.
>
>A continuación pego el resultado:
>
>---
>root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown
>lrwxrwxrwx 1 root staff 14 abr 27 00:48 /usr/local/bin/shutdown ->
>/sbin/shutdown
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
>-rw-r- 1 tesistas fuse 22192 abr 27 00:48 /sbin/shutdown
>
>
>root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot
>lrwxrwxrwx 1 root staff 12 abr 27 00:49 /usr/local/bin/reboot ->
>/sbin/reboot
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/reboot
>lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/halt
>-rw-r- 1 tesistas fuse 13848 abr 27 00:49 /sbin/halt
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/poweroff
>lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/poweroff -> halt
>--
>
>
>Lo que llevo hecho:
>
>1/ Cambié los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt  al
>grupo salir:
>
># chgrp salir  /sbin/shutdown  /sbin/reboot   /sbin/halt
>
>2/ Dí permisos de ejecución a los comandos /sbin/shutdown y /sbin/halt:
>
># chmod u+s,o-rwx  /sbin/shutdown   /sbin/halt
>
>3/ Revisé el estado de los permisos para estos comandos:
>
>-
>root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown
>lrwxrwxrwx 1 root staff 14 oct 10 21:21 /usr/local/bin/shutdown ->
>/sbin/shutdown
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
>-rwSr- 1 tesistas salir 22192 abr 27 00:48 /sbin/shutdown
>
>
>root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot
>lrwxrwxrwx 1 root staff 12 oct 10 21:22 /usr/local/bin/reboot ->
>/sbin/reboot
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/reboot
>lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt
>
>
>root@Tesistas:/home/tesistas#  ls -l /sbin/halt
>-rwSr- 1 tesistas salir 13848 abr 27 00:49 /sbin/halt
>
>
>root@Tesistas:/home/tesistas# ls -l /sbin/poweroff
>lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/poweroff -> halt
>
>
>
>Veo varias cosas:
>
>- /sbin/reboot no cambió de grupo, pero sí lo hicieron /sbin/shutdown
>y /sbin/halt.
>
>- No estoy seguro si están bien los permisos de los enlaces
>simbólicos: lrwxrwxrwx 1 root staff.
>
>- Sigo sin poder apagar/reiniciar como usuari

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

2015-10-10 Por tema Frederit Mogollon 
Este hilo se está haciendo muy largo.
Para no extenderme más, hago un resumen del problema y lo solucionado
hasta ahora (por favor, leer hasta el final):

Sistema: Debian Wheezy + IceWM + SpaceFM + SLiM
Ordenador: CPU 1,7 GHz + 512 RAM + HD 13 GB

Instalación: NetInstall + paquetes oficiales + paquetes propietarios +
scripts propios y de  terceros.

Propósito: General, investigación científica.

Comentarios de interés para esta consulta y breve historial de la instalación:

1). Se creó 1 cuenta de usuario normal (tesistas) para varias personas.

2). Recién instalado, se configuró el sistema para
apagado/reinicio/cierre de sesión sin privilegios de superusuario:

2.1). Como root, creé un grupo llamado salir.
2.2). El usuario fue asignado al grupo salir.
2.3). Los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt se
cambiaron al grupo salir.
2.4).  Asigné permisos de lectura, escritura y ejecución para
propietario, grupo y otros a los comandos del punto anterior.
2.5). Creé enlaces simbólicos de /sbin/shutdown, /sbin/reboot y
/sbin/halt hasta el directorio /usr/local/bin.
2.6). Se editaron varias líneas del archivo /etc/sudoers de la siguiente forma:
 Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
 User_AliasUSERS = tesistas
 Cmnd_AliasSHUTDOWN = /usr/local/bin/shutdown,
/usr/local/bin/halt, /usr/local/bin/reboot
 USERSALL = NOPASSWD: SHUTDOWN
 USERSALL = NOPASSWD: /sbin/poweroff
 %sudo   ALL = (ALL:ALL) ALL

3). Desde el repositorio Wheezy-backports se requirió instalar
p11-kit-modules:i386 y pepperfalashplayer-nonfree.

4). Casi un año de instalado y todo funcionaba bien. Luego, varios
meses atrás, hice "aptitude full-upgrade" con los repositorios
Wheezy-backports habilitados.

5). Hace unos 4-5 días hice "aptitude upgrade" instalándose la
actualización para Wheezy 7.9.


El problema:
   Al usar el ordenador, hace un  par de días, noté que al intentar
apagarlo o reiniciarlo entraba de nuevo en sesión. Al intentarlo desde
la terminal de usuario me denegaba el acceso por falta de permisos.
Igual resultado al intentarlo como superusuario.
   Revisando me percaté de que tampoco tenía acceso a las tareas cron
del usuario, sin privilegios de root, cuando antes lo podía hacer sin
problemas.

Solución parcial:
   El problema con cron se solucionó al hacer "dpkg-reconfigure cron".

Situación actual:
   Aún no he podido solucionar lo de los permisos para
apagado/reinicio. Al comprobar los permisos de los ejecutables
/sbin/shutdown y /sbin/halt veo que el propietario y el grupo de
ambos, tesistas y fuse, respectivamente, no tienen permisos de
ejecución.

A continuación pego el resultado:

---
root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown
lrwxrwxrwx 1 root staff 14 abr 27 00:48 /usr/local/bin/shutdown ->
/sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
-rw-r- 1 tesistas fuse 22192 abr 27 00:48 /sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot
lrwxrwxrwx 1 root staff 12 abr 27 00:49 /usr/local/bin/reboot -> /sbin/reboot


root@Tesistas:/home/tesistas# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt


root@Tesistas:/home/tesistas# ls -l /sbin/halt
-rw-r- 1 tesistas fuse 13848 abr 27 00:49 /sbin/halt


root@Tesistas:/home/tesistas# ls -l /sbin/poweroff
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/poweroff -> halt
--


Lo que llevo hecho:

1/ Cambié los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt  al
grupo salir:

# chgrp salir  /sbin/shutdown  /sbin/reboot   /sbin/halt

2/ Dí permisos de ejecución a los comandos /sbin/shutdown y /sbin/halt:

# chmod u+s,o-rwx  /sbin/shutdown   /sbin/halt

3/ Revisé el estado de los permisos para estos comandos:

-
root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown
lrwxrwxrwx 1 root staff 14 oct 10 21:21 /usr/local/bin/shutdown ->
/sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
-rwSr- 1 tesistas salir 22192 abr 27 00:48 /sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot
lrwxrwxrwx 1 root staff 12 oct 10 21:22 /usr/local/bin/reboot -> /sbin/reboot


root@Tesistas:/home/tesistas# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt


root@Tesistas:/home/tesistas#  ls -l /sbin/halt
-rwSr- 1 tesistas salir 13848 abr 27 00:49 /sbin/halt


root@Tesistas:/home/tesistas# ls -l /sbin/poweroff
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/poweroff -> halt



Veo varias cosas:

- /sbin/reboot no cambió de grupo, pero sí lo hicieron /sbin/shutdown
y /sbin/halt.

- No estoy seguro si están bien los permisos de los enlaces
simbólicos: lrwxrwxrwx 1 root staff.

- Sigo sin poder apagar/reiniciar como usuario normal ni como
superusuario. No tengo permisos.


Con esto me doy cuenta que mis conocimientos sobre GNU/Linux aún son
muy limitados. Sin embargo, el sentido común me dice que falta algo
que permita apagar/reiniciar e

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

2015-10-10 Por tema Frederit Mogollon 
2015-10-10 13:09 GMT-04:30, Santiago Vila :
> On Sat, Oct 10, 2015 at 09:44:40AM -0430, Frederit Mogollon wrote:
>
>> Agradezco el intento. No se si leíste los mensajes anteriores, pero
>> aparentemente no es cron el problema.
>
> Al final sí era cron el problema. Las opciones eran básicamente dos:
>
> * Que la orden crontab no fuera set-gid crontab (la que yo pensaba que
>   al final no era).
>
> * Que el directorio /var/spool/cron/crontabs no fuera del grupo
>   crontab y escribible por el grupo.
>
> El permiso set-gid crontab permite a la orden crontab ejecutarse con
> privilegios del grupo crontab aunque lo ejecute un usuario normal,
> para así para poder escribir en /var/spool/cron/crontabs, por eso
> el directorio es escribible por el grupo y pertenece al grupo crontab.
>

Santiago, esta parte del cuento, pude solucionarlo al ejecutar la
reconfiguración automática de cron con la orden "dpkg-reconfigure
cron", lo cual restauró la asignación del directorio
/var/spool/cron/crontabs al grupo crontab.


> Me vas a decir que "es muy fácil decirlo" pero una vez que entiendes
> cómo funcionan las cosas lo único que hace falta es ir revisando cada
> eslabón de la cadena.
>

Tienes toda la razón. Como todos, cada vez voy aprendiendo más sobre
el entorno GNU/Linux, y en especial de Debian.


> Me leí los mensajes anteriores, sí, pero no entendí qué tienen que ver
> los backports con todo esto. En general los backports no estropean
> cosas.
>


Cuando escribí que cron no era el problema, me refería a que de buenas
a primera pasó algo que alteró la asignación de permisos, tanto a cron
como a los comandos /sbin/halt y /sbin/shutdown, tal como los había
configurado luego de instalar el sistema hace tiempo atrás.

Estoy consciente de que recientemente, no toqué nada de eso. Una
posibilidad en la que había pensado, es que alguien más tuvo acceso al
sistema y alteró los permisos. Sin embargo, esto es poco probable,
porque en el sitio donde estoy soy el único que trato con Debian. Los
demás son fieles seguidores de los sistemas operativos de Redmont y
para nada se meten con otra cosa que no sea usar el navegador web, el
paquete ofimático, el lector de pdf, el visor de imágenes y
reproductor multimedia. Dado que esta máquina es viejita, con solo
unos 10 GB de disco duro y 512 MB de ram, fue Debian GNU/Linux la que
la puso a volar. Y casi a regañadientes, puesto que no hay más
ordenadores disponibles, han aprendido a usar el sistema para lo que
necesitan.

Entonces, el único hecho al que puedo asociar las alteraciones
registradas en los permisos, es la actualización automática de
paquetes a wheezy-backports, considerando que tenía el repositorio
habilitado en el fichero /etc/sources.list.

Saludos

fdm

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

2015-10-10 Por tema Santiago Vila 
On Sat, Oct 10, 2015 at 09:44:40AM -0430, Frederit Mogollon wrote:

> Agradezco el intento. No se si leíste los mensajes anteriores, pero
> aparentemente no es cron el problema.

Al final sí era cron el problema. Las opciones eran básicamente dos:

* Que la orden crontab no fuera set-gid crontab (la que yo pensaba que
  al final no era).

* Que el directorio /var/spool/cron/crontabs no fuera del grupo
  crontab y escribible por el grupo.

El permiso set-gid crontab permite a la orden crontab ejecutarse con
privilegios del grupo crontab aunque lo ejecute un usuario normal,
para así para poder escribir en /var/spool/cron/crontabs, por eso
el directorio es escribible por el grupo y pertenece al grupo crontab.

Me vas a decir que "es muy fácil decirlo" pero una vez que entiendes
cómo funcionan las cosas lo único que hace falta es ir revisando cada
eslabón de la cadena.

Me leí los mensajes anteriores, sí, pero no entendí qué tienen que ver
los backports con todo esto. En general los backports no estropean
cosas.

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

2015-10-10 Por tema Frederit Mogollon 
2015-10-10 10:54 GMT-04:30, Manolo Díaz :
> El viernes, 9 oct 2015 a las 11:38 UTC
> Frederit Mogollon escribió:
>
>> 
>> # shutdown -h now
>> bash: /usr/local/bin/shutdown: Permiso denegado
>> -
>> 
>> # poweroff
>> bash: /sbin/poweroff: Permiso denegado
>> ---
>> ---
>> # reboot
>> bash: /usr/local/bin/reboot: Permiso denegado
>> 
>
> ¿El sistema de ficheros está bien? ¿Has comprobado los permisos de
> alguno de esos ejecutables que te lo deniegan?
>
> --

Hola Manolo, gracias por responder. No lo había hecho.
Al comprobar los permisos de los ejecutables /sbin/shutdown y
/sbin/halt veo que el propietario y el grupo de ambos, tesistas y
fuse, respectivamente, no tienen permisos de ejecución.

Aquí creo es importante destacar, que hace año y medio cuando instalé
este sistema, configuré que el ordenador se apagara/reiniciara desde
el usuario normal, sin privilegios de root, dado que el equipo iba a
ser consultado por muchas personas, dejando un solo usuario.

Para esto, como root, creé un grupo llamado salir, al que asigné al
usuario. Luego, cambié al grupo salir los comandos /sbin/shutdown,
/sbin/reboot y /sbin/halt, y les cambié los permisos a lectura,
escritura y ejecución para todo mundo. Seguidamente, creé enlaces
simbólicos al path del usuario, es decir, al directorio
/usr/local/bin.

A continuación pego el resultado:

---
root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown
lrwxrwxrwx 1 root staff 14 abr 27 00:48 /usr/local/bin/shutdown ->
/sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /sbin/shutdown
-rw-r- 1 tesistas fuse 22192 abr 27 00:48 /sbin/shutdown


root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot
lrwxrwxrwx 1 root staff 12 abr 27 00:49 /usr/local/bin/reboot -> /sbin/reboot


root@Tesistas:/home/tesistas# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/reboot -> halt


root@Tesistas:/home/tesistas# ls -l /sbin/halt
-rw-r- 1 tesistas fuse 13848 abr 27 00:49 /sbin/halt


root@Tesistas:/home/tesistas# ls -l /sbin/poweroff
lrwxrwxrwx 1 root root 4 jul 17  2013 /sbin/poweroff -> halt
---


Me pregunto:
¿Qué pudo haber ocasionado que los comandos /sbin/shutdown y
/sbin/halt perdiesen sus permisos de ejecución, cuando ya se los había
configurado y funcionaba bien?

Aquí especulo sobre la posibilidad de que la actualización de algún
paquete desde wheezy a wheeezy-bacports, relacionado con la asignación
de permisos, sea la causante de la restauración de permisos sobre los
comandos /sbin/shutdown, /sbin/reboot y /sbin/halt, a como queda
acabado de instalar el sistema operativo.


Bueno, para intentar solucionar esto, podría volver a asignar permisos
de lectura, escritura y ejecución a los comandos /sbin/shutdown,
/sbin/reboot y /sbin/halt para el propietario tesistas y el grupo
fuse. Puedo intentar con la opción de "dpkg-reconfigure sysvinit" para
reconfigurar el paquete que proporciona a los comandos antes
mencionados (si funcionó con  cron, puede que funcione con esto).

Saludos

fdm

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

2015-10-10 Por tema Frederit Mogollon 
2015-10-10 10:41 GMT-04:30, Camaleón :
> El Sat, 10 Oct 2015 10:18:07 -0430, Frederit Mogollon escribió:
>
>>>
>> 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).
>

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

Si, la reconfiguración automática del paquete cron surtió efecto!  :)
El grupo del directorio crontabs es nuevamente crontab, y ya puedo ver
las tareas cron de mi usuario sin privilegios de root, que es lo
normal:

---
root@Tesistas:/home/tesistas# dpkg-reconfigure cron
[ ok ] Stopping periodic command scheduler: cron.
[ ok ] Starting periodic command scheduler: cron.



root@Tesistas:/home/tesistas# ls -l /var/spool/cron/
total 12
drwxrwx--T 2 root root4096 abr 17 16:03 atjobs
drwxrwx--T 2 root root4096 oct  3  2014 atspool
drwx-wx--T 2 root crontab 4096 jul 10 01:00 crontabs



root@Tesistas:/home/tesistas# ls -l /var/spool/cron/crontabs/
total 4
-rw--- 1 tesistas crontab 1630 jul 10 01:00 tesistas



tesistas@Tesistas:~$ crontab -l
0 0 13 * * 4  /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril
/home/tesistas/Descargas



tesistas@Tesistas:~$ crontab -e
No modification made
-

Muchas gracias por tu ayuda. Me sirvió de mucho.

Saludos

fdm

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

2015-10-10 Por tema Manolo Díaz 
El viernes, 9 oct 2015 a las 11:38 UTC
Frederit Mogollon escribió:

> 
> # shutdown -h now
> bash: /usr/local/bin/shutdown: Permiso denegado
> -
> 
> # poweroff
> bash: /sbin/poweroff: Permiso denegado
> ---
> ---
> # reboot
> bash: /usr/local/bin/reboot: Permiso denegado
> 

¿El sistema de ficheros está bien? ¿Has comprobado los permisos de
alguno de esos ejecutables que te lo deniegan?

-- 
Manolo Díaz

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

2015-10-10 Por tema Camaleó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

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

2015-10-10 Por tema Frederit Mogollon 
>> root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/
>> total 12 drwx-wx--T 2 root root4096 jul 10 01:00 .
>> drwxr-xr-x 5 root root4096 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

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

2015-10-10 Por tema Camaleón 
El Sat, 10 Oct 2015 02:28:03 -0430, Frederit Mogollon escribió:

> Como actualización en el intento de solucionar el embrollo en que estoy
> metido (sin reinstalar -es lo que estoy intentando no hacer-),
> comento lo que he hecho hasta ahora:

(...)

Como he comentado antes, me parece que sólo un paquete instalado de los 
backports (el kernel) así no tendrás que desactualizar nada :-)

(...)

> 5. La desactualización de los paquetes instalados desde el repositorio
> wheezy-backports, se realizó utilizando la capacidad del comando
> aptitude para resolver dependencias, y considerando el apt-pinning
> anterior:
> 
--
> root@Tesistas:/home/tesistas# aptitude install autopoint bind9-host

(...)

> 8 paquetes serán instalados, 55 desactualizados, 38 eliminados y 28 sin
> actualizar.

Pues no veo que esos paquetes vayan marcados como "-bpo" :-?

(...)

> 10. Habilité de nuevo el repositorio de wheezy-backports, para instalar
> solamente los paquetes p11-kit-modules y pepperflashplugin-nonfree,
> necesarios para la adecuada ejecución de playonlinux y opera-developer,
> respectivamente. Se instalaron con la orden:

Mejor hubiera sido que antes de instalarlos hubieras ejecutado de nuevo 
los comandos que te daban error.

> Luego, la línea del repositorio wheezy-backports en el archivo
> /etc/apt/sources.list, fue comentada.
> Aquí es importante resaltar, que antes de que se suscitara todo este
> rollo, estos 2 paquetes estaban instalados y todo iba de maravilla con
> playonlinux y el navegador web.

Quizá haya sido alguna actualización la que te haya trastocado los 
permisos pero tratándose de wheezy (oldstable) es muy raro.

> 11. Al intentar ver la lista de tareas del crontab del usuario tesistas,
> obtuve la misma respuesta negativa que originó esta consulta en la lista
> debian-user-spanish:

(...)
 
> Al realizar una búsqueda en la página web
> https://packages.debian.org/es/wheezy/ vi que existen versiones de estos
> paquetes tanto para wheezy como para wheezy-backports. Lo que no
> entiendo es ¿por qué no aparecen listados en Synaptic los paquetes no
> instalados equivalentes de la vertiente wheezy?

Tienen que estar, puedes filtrar los paquetes por el origen de los repos 
o simplemente fijarte en si lleva la coletilla "-bpo". Si no la lleva es 
que el paquete es del repo de wheezy convencional, no de los backports.

Saludos,

-- 
Camaleón

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

2015-10-10 Por tema Frederit Mogollon 
>> --
>> $ crontab -l
>>
>> $ crontab/tesistas: fdopen: Permiso denegado
>> 
>
> Con toda probabilidad, no tienes estos permisos:
>
> ls -l /usr/bin/crontab
> -rwxr-sr-x 1 root crontab 36008 jun 11 12:23 /usr/bin/crontab
>
> Reinstala el paquete:
>
> apt-get --reinstall install cron
>

Hola Santiago, gracias por responder. Pues, al ejecutar la orden
sugerida, obtengo los mismos permisos:

---
tesistas@Tesistas:~$ ls -l /usr/bin/crontab

-rwxr-sr-x 1 root crontab 34760 jul  3  2012 /usr/bin/crontab
---

Agradezco el intento. No se si leíste los mensajes anteriores, pero
aparentemente no es cron el problema. Algo pasó que me alteró los
permisos sobre cron, además de poder apagar/reiniciar como usuario
normal, incluso con privilegios de superusuario. Pienso que fue algo
relacionado con algún paquete de wheezy-backports instalado.

Para agregar más datos, probé desde otro usuario creado anteriormente
para ensayos, y obtengo la misma respuesta:

--
sancho@Tesistas:~$ crontab -l

$ crontab/sancho: fdopen: Permiso denegado
 


Al probar reiniciar desde la consola, entrando en el modo recovery
desde el Grub2, obtengo
que ni root puede apagar/reiniciar:

--
root@Tesistas:~# reboot

bash: /sbin/reboot: Permission denied
--


pero al revisar las tareas cron de mi usuario desde la consola, puedo
verla asignada:

-
root@Tesistas:~# crontab -u tesistas -l

0 0 13 * * 4  /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril
/home/tesistas/Descargas
--

Saludos

fdm

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

2015-10-10 Por tema Camaleón 
El Fri, 09 Oct 2015 14:38:04 -0430, Frederit Mogollon escribió:

(...)

>> 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.
>>
>>
> Hola Camaleón. Gracias por responder. Si, siempre había usado esa
> estrategia, pero esta vez me fui de impulso, y como que no es buena idea
> actualizar todo a backports de una.
> 
> 
> 
>>> --
>>> $ crontab/tesistas: fdopen: Permiso denegado
>>> -
>>
>> (...)
>>
>> Comprueba los permisos/propietarios del directorio de tareas de tu
>> usuario:
>>
>> ls -la /var/spool/cron/crontabs/

(...)

> Al hacerlo como root, resulta lo siguiente:
> 
> 
> root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/
> total 12 drwx-wx--T 2 root root4096 jul 10 01:00 .
> drwxr-xr-x 5 root root4096 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/

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

>> 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.
>>
>>
> o.O   Oh no no... tal vez fui yo, que no me supe explicar bien: Clamav
> en ningún momento alteró los permisos de archivos.

(...)

Entendido :-)


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

> Tocará hacer una desactualización de la mayoría de paquetes
> instalados/actualizados desde backports... :/

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

>> 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.
>>
>>
> Sinceramente no veo los logs a menudo, pero al revisar el syslog, hay
> algo que me llama la atención y no sé si es normal, me refiero a la
> descripción "ordered data mode. Opts: (null)" en las siguientes líneas
> del log:

(...)

(nada raro)

> Al listar los  paquetes instalados desde backports, obtengo que son en
> total 120:

(...)

> root@Tesistas:/home/tesistas# for p in $(dpkg -l | grep '^ii' | cut -d '
> ' -f 3); do apt-cache showpkg $p | head -3 | grep -v '^Versions' |
> sed -e 's/Package: //;' | paste - - ; done | grep backports | awk -F
> '\t' '{print $1}'

(...)

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.

Saludos,

-- 
Camaleón

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

2015-10-10 Por tema Santiago Vila 
On Sat, Oct 10, 2015 at 02:28:03AM -0430, Frederit Mogollon wrote:

> --
> $ crontab -l
> 
> $ crontab/tesistas: fdopen: Permiso denegado
> 

Con toda probabilidad, no tienes estos permisos:

ls -l /usr/bin/crontab
-rwxr-sr-x 1 root crontab 36008 jun 11 12:23 /usr/bin/crontab

Reinstala el paquete:

apt-get --reinstall install cron

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

2015-10-09 Por tema Frederit Mogollon 
>
> Al listar los  paquetes instalados desde backports, obtengo que son en
> total 120:
> ---
> root@Tesistas:/home/tesistas# for p in $(dpkg -l | grep '^ii' | cut -d
> ' ' -f 3); do apt-cache showpkg $p | head -3 | grep -v '^Versions' |
> sed -e 's/Package: //;' | paste - - ; done | grep backports | wc -l
> 120
> --
>
> y son:
>
>
> --
> root@Tesistas:/home/tesistas# for p in $(dpkg -l | grep '^ii' | cut -d
> ' ' -f 3); do apt-cache showpkg $p | head -3 | grep -v '^Versions' |
> sed -e 's/Package: //;' | paste - - ; done | grep backports | awk -F
> '\t' '{print $1}'
> autopoint
> bind9-host
> consolekit
> cryptsetup-bin
> desktop-file-utils
> dmidecode
> dnsutils
> file
> geoip-database
> gettext
> gettext-base
> git
> git-man
> gstreamer1.0-libav
> init-system-helpers
> initramfs-tools
> iproute
> iproute2
> irqbalance
> liba52-0.7.4
> libasprintf0c2
> libavutil53
> libbind9-90
> libbsd0
> libck-connector0
> libcryptsetup4
> libdns100
> libdvdnav4
> libdvdread4
> libestr0
> libevdev2
> libgeoip1
> libgettextpo0
> libgnutls-deb0-28
> libgpg-error0
> libgstreamer-plugins-base1.0-0
> libgstreamer1.0-0
> libgudev-1.0-0
> libhogweed2
> libisc95
> libisccc90
> libisccfg90
> libjson-c2
> libjson0
> libldap-2.4-2
> libldb1
> liblogging-stdlog0
> liblwres90
> libmagic1
> libnettle4
> libnl-3-200
> libnl-genl-3-200
> libntdb1
> libopus0
> liborc-0.4-0
> libp11-kit0
> libpam-ck-connector
> libpoppler-glib8
> libpoppler46
> libpulse0
> libqt4-dbus
> libqt4-network
> libqt4-opengl
> libqt4-sql
> libqt4-sql-sqlite
> libqt4-svg
> libqt4-xml
> libqtcore4
> libqtdbus4
> libqtgui4
> libsmbclient
> libsystemd-login0
> libtag1-vanilla
> libtag1c2a
> libtalloc2
> libtasn1-6
> libtdb1
> libtevent0
> libudev1
> libusb-1.0-0
> libwbclient0
> libxapian22
> libxcb-glx0
> libxcb-randr0
> libxcb-render0
> libxcb-shape0
> libxcb-shm0
> libxcb-xv0
> libxcb1
> libxnvctrl0
> linux-image-3.16.0-0.bpo.4-686-pae
> linux-image-686-pae
> linux-libc-dev
> memtest86+
> openssh-client
> p11-kit-modules
> pepperflashplugin-nonfree
> poppler-utils
> python-debian
> python-libtorrent
> python-six
> python-talloc
> python-twisted-bin
> python-twisted-core
> python-twisted-web
> qdbus
> rsyslog
> samba-libs
> shared-mime-info
> slim
> smartmontools
> spacefm
> spacefm-common
> tar
> udev
> udevil
> vim-common
> vim-tiny
> whois
> xserver-xorg-input-synaptics
> --
>

Como actualización en el intento de solucionar el embrollo en que
estoy metido (sin reinstalar -es lo que estoy intentando no hacer-),
comento lo que he hecho hasta ahora:

1. Inhabilité el repositorio de wheezy-backports:
--
root@Tesistas:/home/tesistas# cat /etc/apt/sources.list

# deb cdrom:[Debian GNU/Linux 7.8.0 _Wheezy_ - Official i386 NETINST
Binary-1 20150110-13:31]/ wheezy main

deb http://cdn.debian.net/debian/ wheezy main contrib non-free
deb-src http://cdn.debian.net/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
deb http://cdn.debian.net/debian/ wheezy-updates main contrib non-free
deb-src http://cdn.debian.net/debian/ wheezy-updates main

#deb http://http.debian.net/debian wheezy-backports main contrib
--



2. Actualicé la lista de paquetes en el caché de apt

root@Tesistas:/home/tesistas# aptitude update
--


3. Creé el archivo /etc/apt/preferences para configurar apt a que
instalara versiones de paquetes desde el repositorio de wheezy:


root@Tesistas:/home/tesistas# cat  /etc/apt/preferences

Package: *
Pin: release n=wheezy
Pin-Priority: 1001
-


4. Intenté desactualizar los paquetes instalados, pero no se ejecutó la acción:
-
root@Tesistas:/home/tesistas# aptitude safe-upgrade

No se instalará, actualizará o eliminará ningún paquete.
0 paquet

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

2015-10-09 Por tema Frederit Mogollon 
>> 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.
>



Hola Camaleón. Gracias por responder. Si, siempre había usado esa
estrategia, pero esta vez me fui de impulso, y como que no es buena
idea actualizar todo a backports de una.



>> --
>> $ crontab/tesistas: fdopen: Permiso denegado
>> -
>
> (...)
>
> Comprueba los permisos/propietarios del directorio de tareas de tu
> usuario:
>
> ls -la /var/spool/cron/crontabs/
>

Al intentar leer los permisos obtengo esto:

-
tesistas@Tesistas:~$ ls -la /var/spool/cron/crontabs/
ls: no se puede abrir el directorio /var/spool/cron/crontabs/: Permiso denegado
-


Al hacerlo como root, resulta lo siguiente:

--
root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/
total 12
drwx-wx--T 2 root root4096 jul 10 01:00 .
drwxr-xr-x 5 root root4096 abr 17 16:01 ..
-rw--- 1 tesistas crontab 1630 jul 10 01:00 tesistas
---


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

o.O   Oh no no... tal vez fui yo, que no me supe explicar bien: Clamav
en ningún momento alteró los permisos de archivos.
Solamente hice la referencia para denotar contextualmente que la
ejecución de tareas asignadas a cron desde crontab del usuario
tesistas (usuario normal), funcionaba perfectamente, y que de esto me
cercioré al observar que el antivirus se ejecutaba al tiempo
programado, aún cuando no mostraba el crontab del usuario.


>
> Eso de añadir tu usuario al grupo crontab no debería ser necesario :-?

Si, lo sé..., antes funcionaba y no había sido necesario añadirlo,
pero intenté esa opción para ver si con ello el usuario tesistas
obtenía de nuevo permisos en su otrora crontab de usuario.


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

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.


>
> El kernel no suele hacer esas maldades de tocar los permisos, cuando te
> toca las narices usa otros "métodos".
>

Si, descarté su participación en este rompecabezas...


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

Tocará hacer una desactualización de la mayoría de paquetes
instalados/actualizados desde backports... :/


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

Sinceramente no veo los logs a menudo, pero al revisar el syslog, hay
algo que me llama la atención y no sé si es normal, me refiero a la
descripción "ordered data mode. Opts: (null)" en las siguientes líneas
del log:

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

2015-10-09 Por tema Camaleó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

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

2015-10-09 Por tema Frederit Mogollon 
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.

## Primero, el contexto:

Les escribo desde un sistema Debian Wheezy 7.9 + IceWM + SpaceFM +
SLiM, instalado en una PC de escritorio, con 512 MB de RAM y 10 GB de
HD IDE. Los kernels instalados son:

linux-image-3.16.0-0.bpo.4-686-pae
linux-image-3.2.0-4-686-pae

La lista de repositorios es:

---
root@Tesistas:/home/tesistas# cat /etc/apt/sources.list

# deb cdrom:[Debian GNU/Linux 7.8.0 _Wheezy_ - Official i386 NETINST
Binary-1 20150110-13:31]/ wheezy main

deb http://cdn.debian.net/debian/ wheezy main contrib non-free
deb-src http://cdn.debian.net/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
deb http://cdn.debian.net/debian/ wheezy-updates main contrib non-free
deb-src http://cdn.debian.net/debian/ wheezy-updates main

deb http://http.debian.net/debian wheezy-backports main contrib

#deb http://www.deb-multimedia.org wheezy main non-free
#deb-src http://cdn.debian.net/debian/ wheezy main
---


## Ahora, el problema e intentos de solucionarlo.

Desde la versión Debian 7.8 había asignado el escaneado automático del
sistema con clamav, mediante crontab desde el usuario normal. Aclaro,
que funcionaba perfecto.

En el lapso de los últimos 15 días, actualicé un par de veces el
sistema, con las líneas:

---
$ sudo aptitude update
$ sudo aptitude upgrade
-

siendo la última actualización entre ayer y hoy.

Al intentar modificar la tarea de ejecución de clamav desde crontab,
con las órdenes

--
$ crontab -l
$ crontab -e


obtuve la siguiente respuesta:

--
$ crontab/tesistas: fdopen: Permiso denegado
-

cuando antes se listaba la única tarea asignada en el crontab del
usuario tesistas. Se que aún existe tal asignación puesto que el
clamscan se ejecutó a la hora que lo tenía programado inicialmente.

Luego de leer los manuales de cron/crontab, me percaté que en el
directorio /var/spool/cron/crontabs/  se halla un archivo con el
nombre del usuario (tesistas), y que contiene la tarea asignada al
crontab.

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.

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
-

# poweroff
bash: /sbin/poweroff: Permiso denegado
---
---
# reboot
bash: /usr/local/bin/reboot: Permiso denegado


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.

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.


A continuación pego el contenido de dos archivos log relevantes:

---
# cat /var/log/aptitude

Aptitude 0.6.8.2: informe de registro
vie, oct  9 2015 02:29:56 -0430

IMPORTANTE: este registro sólo muestra las acciones que se pretenden
realizar. Puede que no se completen algunas acciones por fallos de dpkg.

Se instalarán 4 paquetes y se eliminarán 0.
Se usar