Re: Crear lanzadores con permisos de superusuario.

[José María]

El vie, 31-03-2023 a las 13:24 +0200, Ramses escribió:
> El 30 de marzo de 2023 21:33:51 CEST, "José María"
>  escribió:
> > El mié, 29-03-2023 a las 22:00 +0200, Ramses escribió:
> > > Hola a tod@s,
> > > 
> > > Tengo estos dos lanzadores en mi Escritorio:
> > > 
> > > [Desktop Entry]
> > > Name=Zenmap
> > > GenericName=GUI Port Scanner
> > > TryExec=zenmap
> > > Exec=zenmap %F
> > > Terminal=false
> > > Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> > > Type=Application
> > > Categories=Application;Network;Security;
> > > Comment=A cross-platform GUI for the Nmap Security Scanner.
> > > Keywords=network;scan;scanner;IP;security;
> > > 
> > > 
> > > [Desktop Entry]
> > > Name=Zenmap (as root)
> > > GenericName=GUI Port Scanner
> > > TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
> > > Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> > > Terminal=false
> > > Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> > > Type=Application
> > > Categories=Application;Network;Security;
> > > Comment=A cross-platform GUI for the Nmap Security Scanner.
> > > Keywords=network;scan;scanner;IP;security;
> > > 
> > > Si ejecuto el primero "Name=Zenmap", me dice que se está
> > > intentando
> > > ejecutar el programa con un usuario que no tiene permisos, y a
> > > continuación me lo abre.
> > > 
> > > Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> > > 
> > > Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-
> > > to-
> > > zenmap.sh" del segundo, no hace nada, pero si en el terminal le
> > > antepongo el "sudo" a esa línea "sudo /usr/local/share/zenmap/su-
> > > to-
> > > zenmap.sh", se abre sin problemas.
> > > 
> > > He probado a ponerles "sudo" al principio de las lineas en los
> > > comandos de los lanzadores, pero me da error.
> > > 
> > > ¿Alguna ayuda de cómo modificar loas lanzadores para que me los
> > > ejecute como root?
> > > 
> > > 
> > > Saludos y gracias
> > > 
> > 
> > Hola,
> > 
> > Se me ocurre una forma algo "sucia"... Pruébalo antes en una
> > máquina
> > virtual. No me hago responsable.
> > 
> > Primero añade a tu usuario y al ejecutable de zenmap a sudo.
> > Ejecuta:
> >  
> > sudo visudo
> > 
> > 
> > Añade la siguiente línea al archivo. Si tu usuario fuese "jose"
> > 
> > joseALL=NOPASSWD: /usr/local/share/zenmap/su-to-zenmap.sh %F
> > 
> > Con esto se supone que no te pide la contraseña al ejecutar la
> > aplicación con sudo
> > 
> > 
> > Ahora tendrás que editar el lanzador y ponerle sudo al ejecutable,
> > o
> > sea, busca la siguiente línea y déjala así
> > 
> > Exec=sudo /usr/local/share/zenmap/su-to-zenmap.sh %F
> > 
> > 
> > Si no funciona, déjalo todo como estaba
> > 
> > No hace falta que te diga que esto no es lo correcto... pero puede
> > ser
> > una solución mientras buscas algo mas ortodoxo
> > 
> > Un saludo,
> > Jose
> > 
> > 
> > 
> > 
> > 
> 
> Hola José María,
> 
> Así, sí va fino...
> 
> ¿Problemas?
> 
> 
> Saludos y gracias
> 


¿Problemas dices?... En teoría no, solo comprueba si ejecutando otra
aplicación con "sudo" te pide la contraseña, por ejemplo actualiza el
sistema con:

sudo apt update

Si todo va bien lo puedes dejar así, solo debes tener en cuenta que
para zenmap nunca te va a pedir la contraseña... 


¿Te quieres complicar la vida? Deshaz todo y te cuento...


Ya he leído que usas Ubuntu, pero no dices el entorno de escritorio que
usas... eso también influye, tanto la distribución como el entorno de
escritorio.

Me explico, si usas un gestor de ventanas como Openbox, JWM etc o usas
Cinnamon, XFCE, Unity o GNOME2, tendrías que instalar el paquete
"policykit-1-gnome"

¡¡¡OJO!!! esto es sólo en Debian, así que tendrías que mirar el paquete
que corresponde a Ubuntu

El entorno de escritorio de Mate, aunque sea un fork de GNOME2 tiene su
propio policykit, al igual que LXDE, LXQT o GNOME3

Si usas este último, tendrías que crear una acción ya que usa pkexec
para que cuando ejecutes la aplicación se te abra un dialogo que te
pregunte por la contraseña.


Te dejo un link con lo que tendrías que hacer porque es un poco largo
de explicar

https://geekland.eu/crear-accion-de-policykit-abrir-aplicacion-root/


Hay que echarle tiempo, paciencia y usar el método de prueba y error...
Hasta aquí te puedo ayudar

Un saludo

Re: Crear lanzadores con permisos de superusuario.

[Camaleón]

El 2023-03-31 a las 12:48 +0200, Ramses escribió:

> El 30 de marzo de 2023 12:50:51 CEST, "Camaleón"  
> escribió:

(...)

> >> >> 
> >> >> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que 
> >> >> al ejecutar el lanzador automáticamente se ejecute con otro usuario, es 
> >> >> decir, como "root"?
> >> >
> >> >¿Has probado lo que recomiendan en el enlace?
> >> >
> >> >Comprueba que tienes todos los paquetes necesarios instalados.
> >> >
> >> >How to Install Zenmap on Ubuntu 22.04
> >> >https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/
> >> >
> >> >Y revisa los comentarios donde dicen que NO funciona con Python3.
> >> >
> >> >Saludos,
> >> >
> >> 
> >> Camaleón, ese enlace ya lo había revisado, y me daba problemas de 
> >> dependencias al instalar la librería que proponen en el proceso, el tema 
> >> de la instalación de GTK, creo recordar.
> >
> >No me refiero a ESE enlace, sino al primero que te he puesto :-)
> >
> >> Finalmente di con este enlace, que coge el código fuente, hace una 
> >> modificación de "path" en los ficheros y se hace la compilación e 
> >> instalación.
> >> 
> >> Sí ejecuto "sudo zenmap" desde un terminal, "zenmap" arranca en entorno 
> >> gráfico sin problemas. La historia está en crear un lanzador en el Entorno 
> >> Gráfico, que no consigo crear el lanzador para que me ejecute "sudo 
> >> zenmap". También he probado con "pkexec zenmap", pero me da error el 
> >> lanzador, pero si ejecuto esa orden desde un terminal, funciona 
> >> perfectamente.
> >> 
> >> No sé si me explico...
> >
> >Entiendo lo que te pasa, pero no sé si el error se debe a que no has 
> >instalado las dependencias que necesita el paquete para iniciarse o se 
> >trata de un problema con el lanzador del escritorio que necesita 
> >conferir los permisos de súperusaurio de la manera adecuada a tu 
> >entorno.
> >
> >Unas preguntas sencillas:
> >
> >1. ¿Qué versión de Debian y qué entorno gráfico tienes instalado?
> >2. ¿Qué sucede cuando ejecutas zenmap desde una consola como root? ¿Se 
> >inicia? ¿Saca algún error? ¿Qué te dice?
> >
> 
> Camaleón, buenos días.
> 
> Tengo UBUNTU 22.04

Vale, entonces es una versión moderna que NO admite de manera nativa 
Zenmap.

> Desde la Consola:

(...)

> - Con mi Usuario ejecuto "sudo /usr/local/share/zenmap/su-to-zenmap.sh", se 
> abre "zenmap".
> 
> - Con root (entrando con "su root" y password) ejecuto "zenmap" y se abre 
> "zenmap".
> 
> - Con root (entrando con "su root" y password) ejecuto 
> "/usr/local/share/zenmap/su-to-zenmap.sh" y se abre "zenmap".

Bien, entonces el problema que tienes es únicamente con el lanzador, 
proque ya has resuelto la instalación de Python2 que necesita la 
aplicación, de otra forma no podría ejecutarse ni iniciarse Zenmap.

(...)

> Vamos, que si lo tiro desde la Consola, funciona "zenmap", pero no consigo 
> que funcione desde un lanzador para root, porque cuando ejecuto el lanzador 
> para Usuario, se comporta igual que cuando tiro el "zenmap" desde Consola 
> como Usuario, pero cuando ejecuto el lanzador para "root", se comporta como 
> cuando ejecuto "/usr/local/share/zenmap/su-to-zenmap.sh" desde la Consola 
> como Usuario, que no hace nada.

El guión que utiliza el apquete Zenmap no está pensando para sistemas 
actuales que se basan el Policykit/pxexec, como ya te dije.

Lo que tienes que hacer es adapatar el sistema de autentificación en 
entorno gráfico como root para que funcione, y poner esa orden en el 
archivo .desktop de Zenmap, para lo cual podrías basarte en el lanzador 
de alguna aplicación similar, como «ettercap-graphical», que usa la 
siguiente orden en el guión al que llama el lanzador: 

pkexec --disable-internal-agent "ethercap" "@"

O Synapctic, que usa un guión ubicado «/usr/bin/synaptic-pkexec»:

pkexec "/usr/sbin/synaptic" "$@"

Pero además necesitarás alguna regla o política definida en Policykit 
para que te funcione, entiendo que sólo con el lanzador no será suficiente.

Revisa lo que están haciendo otras distribuciones para adaptar ese  
paquete a los nuevos entornos, p. ej. en Archlinux, pro si te da alguna 
idea:

https://aur.archlinux.org/packages/zenmap

Saludos,

-- 
Camaleón 

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 21:33:51 CEST, "José María"  
escribió:
>El mié, 29-03-2023 a las 22:00 +0200, Ramses escribió:
>> Hola a tod@s,
>> 
>> Tengo estos dos lanzadores en mi Escritorio:
>> 
>> [Desktop Entry]
>> Name=Zenmap
>> GenericName=GUI Port Scanner
>> TryExec=zenmap
>> Exec=zenmap %F
>> Terminal=false
>> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
>> Type=Application
>> Categories=Application;Network;Security;
>> Comment=A cross-platform GUI for the Nmap Security Scanner.
>> Keywords=network;scan;scanner;IP;security;
>> 
>> 
>> [Desktop Entry]
>> Name=Zenmap (as root)
>> GenericName=GUI Port Scanner
>> TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
>> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>> Terminal=false
>> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
>> Type=Application
>> Categories=Application;Network;Security;
>> Comment=A cross-platform GUI for the Nmap Security Scanner.
>> Keywords=network;scan;scanner;IP;security;
>> 
>> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando
>> ejecutar el programa con un usuario que no tiene permisos, y a
>> continuación me lo abre.
>> 
>> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>> 
>> Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-to-
>> zenmap.sh" del segundo, no hace nada, pero si en el terminal le
>> antepongo el "sudo" a esa línea "sudo /usr/local/share/zenmap/su-to-
>> zenmap.sh", se abre sin problemas.
>> 
>> He probado a ponerles "sudo" al principio de las lineas en los
>> comandos de los lanzadores, pero me da error.
>> 
>> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los
>> ejecute como root?
>> 
>> 
>> Saludos y gracias
>> 
>
>Hola,
>
>Se me ocurre una forma algo "sucia"... Pruébalo antes en una máquina
>virtual. No me hago responsable.
>
>Primero añade a tu usuario y al ejecutable de zenmap a sudo. Ejecuta:
> 
>sudo visudo
>
>
>Añade la siguiente línea al archivo. Si tu usuario fuese "jose"
>
>jose   ALL=NOPASSWD: /usr/local/share/zenmap/su-to-zenmap.sh %F
>
>Con esto se supone que no te pide la contraseña al ejecutar la
>aplicación con sudo
>
>
>Ahora tendrás que editar el lanzador y ponerle sudo al ejecutable, o
>sea, busca la siguiente línea y déjala así
>
>Exec=sudo /usr/local/share/zenmap/su-to-zenmap.sh %F
>
>
>Si no funciona, déjalo todo como estaba
>
>No hace falta que te diga que esto no es lo correcto... pero puede ser
>una solución mientras buscas algo mas ortodoxo
>
>Un saludo,
>Jose
>
>
>
>
>

Hola José María,

Así, sí va fino...

¿Problemas?


Saludos y gracias

Re: Crear lanzadores con permisos de superusuario.

[Pitu Odena]

El 31/3/23 a les 12:53, Ramses ha escrit:

El 30 de marzo de 2023 18:50:50 CEST, Pitu Odena  
escribió:

Prueba con kdesu ( o gnomesu, o xdg-su,... ) en lugar de sudo.


Esas opciones he leído que están obsoletas, ¿no?.


Saludos

No se si estan obsoletas. Solo se que si quiero ejecutar algun programa 
como root desde el lanzador de aplicaciones (Alt+F2) con sudo no 
funciona pero si con kdesu (uso KDE). Supongo (no estoy seguro) que en 
*.desktop pasa lo mismo.


Se trataria de poner :

kdesu Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F

Por probar no se pierde nada.

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 21:22:12 CEST, Carlos Villiere  
escribió:
>El mié, 29-03-2023 a las 22:00 +0200, Ramses escribió:
>> Hola a tod@s,
>> 
>> Tengo estos dos lanzadores en mi Escritorio:
>> 
>> [Desktop Entry]
>> Name=Zenmap
>> GenericName=GUI Port Scanner
>> TryExec=zenmap
>> Exec=zenmap %F
>> Terminal=false
>> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
>> Type=Application
>> Categories=Application;Network;Security;
>> Comment=A cross-platform GUI for the Nmap Security Scanner.
>> Keywords=network;scan;scanner;IP;security;
>> 
>> 
>> [Desktop Entry]
>> Name=Zenmap (as root)
>> GenericName=GUI Port Scanner
>> TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
>> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>> Terminal=false
>> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
>> Type=Application
>> Categories=Application;Network;Security;
>> Comment=A cross-platform GUI for the Nmap Security Scanner.
>> Keywords=network;scan;scanner;IP;security;
>> 
>> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando
>> ejecutar el programa con un usuario que no tiene permisos, y a
>> continuación me lo abre.
>> 
>> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>> 
>> Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-to-
>> zenmap.sh" del segundo, no hace nada, pero si en el terminal le
>> antepongo el "sudo" a esa línea "sudo /usr/local/share/zenmap/su-to-
>> zenmap.sh", se abre sin problemas.
>> 
>> He probado a ponerles "sudo" al principio de las lineas en los
>> comandos de los lanzadores, pero me da error.
>> 
>> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los
>> ejecute como root?
>> 
>> 
>> Saludos y gracias
>> 
>
>Hola Ramses
>
>Probaste de cambiar los permisos a "su-to-zenmap.sh"
>
>Saludos
>

Hola la Carlos,

No he probado, tiene 755 root:root

Los he cambiado para mí Usuario, y nada.


Saludos

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 18:50:50 CEST, Pitu Odena  
escribió:
>Prueba con kdesu ( o gnomesu, o xdg-su,... ) en lugar de sudo.
>

Esas opciones he leído que están obsoletas, ¿no?.


Saludos

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 21:19:01 CEST, Carlos Villiere  
escribió:
>El jue, 30-03-2023 a las 08:21 +0200, Camaleón escribió:
>> su-to-zenmap.sh
>Probaste de cambiar los permisos de "su-to-zenmap.sh"
>

No, tiene permisos 755 root:root


Saludos

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 12:50:51 CEST, "Camaleón"  escribió:
>El 2023-03-30 a las 12:32 +0200, Ramses escribió:
>
>> El 30 de marzo de 2023 11:53:03 CEST, "Camaleón"  
>> escribió:
>> >El 2023-03-30 a las 11:33 +0200, Ramses escribió:
>> >> El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  
>> >> escribió:
>> >> >El 2023-03-29 a las 22:00 +0200, Ramses escribió:
>> >> >
>> >> >> Tengo estos dos lanzadores en mi Escritorio:
>> >> >
>> >> >(...)
>> >> >
>> >> >> [Desktop Entry]
>> >> >(...)
>> >> >> Exec=zenmap %F
>> >> >
>> >> >> [Desktop Entry]
>> >> >(...)
>> >> >> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>> >> >> 
>> >> >> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando 
>> >> >> ejecutar el programa con un usuario que no tiene permisos, y a 
>> >> >> continuación me lo abre.
>> >> >> 
>> >> >> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>> >> >> 
>> >> >> Si en un terminal ejecuto esta línea 
>> >> >> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, 
>> >> >> pero si en el terminal le antepongo el "sudo" a esa línea "sudo 
>> >> >> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
>> >> >> 
>> >> >> He probado a ponerles "sudo" al principio de las lineas en los 
>> >> >> comandos de los lanzadores, pero me da error.
>> >> >
>> >> >Se trata de un bug conocido del paquete que además ya no lo veo 
>> >> >disponible en las nuevas versiones de Debian:
>> >> >
>> >> >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
>> >> > 
>> >> >> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los 
>> >> >> ejecute como root?
>> >> >
>> >> >Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
>> >> >necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
>> >> >aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
>> >> >actuales de Debian ya no se usan (están policykit, pkexec y demás 
>> >> >moderneces).
>> >> >
>> >> >En cualquier caso, siempre podrás create un nuevo lanzador que se 
>> >> >ajuste a lo que tengas instalado, según la versión de Debian que 
>> >> >tengas.
>> >> >
>> >> >Mira a ver si te sirve lo que indican por aquí:
>> >> >
>> >> >Zenmap (as root) not working on Manjaro
>> >> >https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
>> >> >
>> >> Buenos días,
>> >> 
>> >> Ya había probado a anteponer el comando "pkexec" a la línea del comando 
>> >> editando el fichero del lanzador, pero me pone el lanzador con error, 
>> >> como no ejecutable.
>> >> 
>> >> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
>> >> ejecutar el lanzador automáticamente se ejecute con otro usuario, es 
>> >> decir, como "root"?
>> >
>> >¿Has probado lo que recomiendan en el enlace?
>> >
>> >Comprueba que tienes todos los paquetes necesarios instalados.
>> >
>> >How to Install Zenmap on Ubuntu 22.04
>> >https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/
>> >
>> >Y revisa los comentarios donde dicen que NO funciona con Python3.
>> >
>> >Saludos,
>> >
>> 
>> Camaleón, ese enlace ya lo había revisado, y me daba problemas de 
>> dependencias al instalar la librería que proponen en el proceso, el tema de 
>> la instalación de GTK, creo recordar.
>
>No me refiero a ESE enlace, sino al primero que te he puesto :-)
>
>> Finalmente di con este enlace, que coge el código fuente, hace una 
>> modificación de "path" en los ficheros y se hace la compilación e 
>> instalación.
>> 
>> Sí ejecuto "sudo zenmap" desde un terminal, "zenmap" arranca en entorno 
>> gráfico sin problemas. La historia está en crear un lanzador en el Entorno 
>> Gr

Re: Crear lanzadores con permisos de superusuario.

[José María]

El mié, 29-03-2023 a las 22:00 +0200, Ramses escribió:
> Hola a tod@s,
> 
> Tengo estos dos lanzadores en mi Escritorio:
> 
> [Desktop Entry]
> Name=Zenmap
> GenericName=GUI Port Scanner
> TryExec=zenmap
> Exec=zenmap %F
> Terminal=false
> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> Type=Application
> Categories=Application;Network;Security;
> Comment=A cross-platform GUI for the Nmap Security Scanner.
> Keywords=network;scan;scanner;IP;security;
> 
> 
> [Desktop Entry]
> Name=Zenmap (as root)
> GenericName=GUI Port Scanner
> TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> Terminal=false
> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> Type=Application
> Categories=Application;Network;Security;
> Comment=A cross-platform GUI for the Nmap Security Scanner.
> Keywords=network;scan;scanner;IP;security;
> 
> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando
> ejecutar el programa con un usuario que no tiene permisos, y a
> continuación me lo abre.
> 
> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> 
> Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-to-
> zenmap.sh" del segundo, no hace nada, pero si en el terminal le
> antepongo el "sudo" a esa línea "sudo /usr/local/share/zenmap/su-to-
> zenmap.sh", se abre sin problemas.
> 
> He probado a ponerles "sudo" al principio de las lineas en los
> comandos de los lanzadores, pero me da error.
> 
> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los
> ejecute como root?
> 
> 
> Saludos y gracias
> 

Hola,

Se me ocurre una forma algo "sucia"... Pruébalo antes en una máquina
virtual. No me hago responsable.

Primero añade a tu usuario y al ejecutable de zenmap a sudo. Ejecuta:
 
sudo visudo


Añade la siguiente línea al archivo. Si tu usuario fuese "jose"

joseALL=NOPASSWD: /usr/local/share/zenmap/su-to-zenmap.sh %F

Con esto se supone que no te pide la contraseña al ejecutar la
aplicación con sudo


Ahora tendrás que editar el lanzador y ponerle sudo al ejecutable, o
sea, busca la siguiente línea y déjala así

Exec=sudo /usr/local/share/zenmap/su-to-zenmap.sh %F


Si no funciona, déjalo todo como estaba

No hace falta que te diga que esto no es lo correcto... pero puede ser
una solución mientras buscas algo mas ortodoxo

Un saludo,
Jose

Re: Crear lanzadores con permisos de superusuario.

[Carlos Villiere]

El mié, 29-03-2023 a las 22:00 +0200, Ramses escribió:
> Hola a tod@s,
> 
> Tengo estos dos lanzadores en mi Escritorio:
> 
> [Desktop Entry]
> Name=Zenmap
> GenericName=GUI Port Scanner
> TryExec=zenmap
> Exec=zenmap %F
> Terminal=false
> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> Type=Application
> Categories=Application;Network;Security;
> Comment=A cross-platform GUI for the Nmap Security Scanner.
> Keywords=network;scan;scanner;IP;security;
> 
> 
> [Desktop Entry]
> Name=Zenmap (as root)
> GenericName=GUI Port Scanner
> TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> Terminal=false
> Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
> Type=Application
> Categories=Application;Network;Security;
> Comment=A cross-platform GUI for the Nmap Security Scanner.
> Keywords=network;scan;scanner;IP;security;
> 
> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando
> ejecutar el programa con un usuario que no tiene permisos, y a
> continuación me lo abre.
> 
> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> 
> Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-to-
> zenmap.sh" del segundo, no hace nada, pero si en el terminal le
> antepongo el "sudo" a esa línea "sudo /usr/local/share/zenmap/su-to-
> zenmap.sh", se abre sin problemas.
> 
> He probado a ponerles "sudo" al principio de las lineas en los
> comandos de los lanzadores, pero me da error.
> 
> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los
> ejecute como root?
> 
> 
> Saludos y gracias
> 

Hola Ramses

Probaste de cambiar los permisos a "su-to-zenmap.sh"

Saludos

Re: Crear lanzadores con permisos de superusuario.

[Carlos Villiere]

El jue, 30-03-2023 a las 08:21 +0200, Camaleón escribió:
> su-to-zenmap.sh
Probaste de cambiar los permisos de "su-to-zenmap.sh"

Re: Crear lanzadores con permisos de superusuario.

[Pitu Odena]

Prueba con kdesu ( o gnomesu, o xdg-su,... ) en lugar de sudo.

Re: Crear lanzadores con permisos de superusuario.

[Camaleón]

El 2023-03-30 a las 12:32 +0200, Ramses escribió:

> El 30 de marzo de 2023 11:53:03 CEST, "Camaleón"  
> escribió:
> >El 2023-03-30 a las 11:33 +0200, Ramses escribió:
> >> El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  
> >> escribió:
> >> >El 2023-03-29 a las 22:00 +0200, Ramses escribió:
> >> >
> >> >> Tengo estos dos lanzadores en mi Escritorio:
> >> >
> >> >(...)
> >> >
> >> >> [Desktop Entry]
> >> >(...)
> >> >> Exec=zenmap %F
> >> >
> >> >> [Desktop Entry]
> >> >(...)
> >> >> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> >> >> 
> >> >> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando 
> >> >> ejecutar el programa con un usuario que no tiene permisos, y a 
> >> >> continuación me lo abre.
> >> >> 
> >> >> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> >> >> 
> >> >> Si en un terminal ejecuto esta línea 
> >> >> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, 
> >> >> pero si en el terminal le antepongo el "sudo" a esa línea "sudo 
> >> >> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
> >> >> 
> >> >> He probado a ponerles "sudo" al principio de las lineas en los comandos 
> >> >> de los lanzadores, pero me da error.
> >> >
> >> >Se trata de un bug conocido del paquete que además ya no lo veo 
> >> >disponible en las nuevas versiones de Debian:
> >> >
> >> >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
> >> > 
> >> >> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute 
> >> >> como root?
> >> >
> >> >Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
> >> >necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
> >> >aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
> >> >actuales de Debian ya no se usan (están policykit, pkexec y demás 
> >> >moderneces).
> >> >
> >> >En cualquier caso, siempre podrás create un nuevo lanzador que se 
> >> >ajuste a lo que tengas instalado, según la versión de Debian que 
> >> >tengas.
> >> >
> >> >Mira a ver si te sirve lo que indican por aquí:
> >> >
> >> >Zenmap (as root) not working on Manjaro
> >> >https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
> >> >
> >> Buenos días,
> >> 
> >> Ya había probado a anteponer el comando "pkexec" a la línea del comando 
> >> editando el fichero del lanzador, pero me pone el lanzador con error, como 
> >> no ejecutable.
> >> 
> >> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
> >> ejecutar el lanzador automáticamente se ejecute con otro usuario, es 
> >> decir, como "root"?
> >
> >¿Has probado lo que recomiendan en el enlace?
> >
> >Comprueba que tienes todos los paquetes necesarios instalados.
> >
> >How to Install Zenmap on Ubuntu 22.04
> >https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/
> >
> >Y revisa los comentarios donde dicen que NO funciona con Python3.
> >
> >Saludos,
> >
> 
> Camaleón, ese enlace ya lo había revisado, y me daba problemas de 
> dependencias al instalar la librería que proponen en el proceso, el tema de 
> la instalación de GTK, creo recordar.

No me refiero a ESE enlace, sino al primero que te he puesto :-)

> Finalmente di con este enlace, que coge el código fuente, hace una 
> modificación de "path" en los ficheros y se hace la compilación e instalación.
> 
> Sí ejecuto "sudo zenmap" desde un terminal, "zenmap" arranca en entorno 
> gráfico sin problemas. La historia está en crear un lanzador en el Entorno 
> Gráfico, que no consigo crear el lanzador para que me ejecute "sudo zenmap". 
> También he probado con "pkexec zenmap", pero me da error el lanzador, pero si 
> ejecuto esa orden desde un terminal, funciona perfectamente.
> 
> No sé si me explico...

Entiendo lo que te pasa, pero no sé si el error se debe a que no has 
instalado las dependencias que necesita el paquete para iniciarse o se 
trata de un problema con el lanzador del escritorio que necesita 
conferir los permisos de súperusaurio de la manera adecuada a tu 
entorno.

Unas preguntas sencillas:

1. ¿Qué versión de Debian y qué entorno gráfico tienes instalado?
2. ¿Qué sucede cuando ejecutas zenmap desde una consola como root? ¿Se 
inicia? ¿Saca algún error? ¿Qué te dice?

Saludos,

-- 
Camaleón 

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 12:32:13 CEST, Ramses  
escribió:
>El 30 de marzo de 2023 11:53:03 CEST, "Camaleón"  escribió:
>>El 2023-03-30 a las 11:33 +0200, Ramses escribió:
>>> El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  
>>> escribió:
>>> >El 2023-03-29 a las 22:00 +0200, Ramses escribió:
>>> >
>>> >> Tengo estos dos lanzadores en mi Escritorio:
>>> >
>>> >(...)
>>> >
>>> >> [Desktop Entry]
>>> >(...)
>>> >> Exec=zenmap %F
>>> >
>>> >> [Desktop Entry]
>>> >(...)
>>> >> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>>> >> 
>>> >> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando 
>>> >> ejecutar el programa con un usuario que no tiene permisos, y a 
>>> >> continuación me lo abre.
>>> >> 
>>> >> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>>> >> 
>>> >> Si en un terminal ejecuto esta línea 
>>> >> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, 
>>> >> pero si en el terminal le antepongo el "sudo" a esa línea "sudo 
>>> >> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
>>> >> 
>>> >> He probado a ponerles "sudo" al principio de las lineas en los comandos 
>>> >> de los lanzadores, pero me da error.
>>> >
>>> >Se trata de un bug conocido del paquete que además ya no lo veo 
>>> >disponible en las nuevas versiones de Debian:
>>> >
>>> >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
>>> > 
>>> >> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute 
>>> >> como root?
>>> >
>>> >Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
>>> >necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
>>> >aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
>>> >actuales de Debian ya no se usan (están policykit, pkexec y demás 
>>> >moderneces).
>>> >
>>> >En cualquier caso, siempre podrás create un nuevo lanzador que se 
>>> >ajuste a lo que tengas instalado, según la versión de Debian que 
>>> >tengas.
>>> >
>>> >Mira a ver si te sirve lo que indican por aquí:
>>> >
>>> >Zenmap (as root) not working on Manjaro
>>> >https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
>>> >
>>> Buenos días,
>>> 
>>> Ya había probado a anteponer el comando "pkexec" a la línea del comando 
>>> editando el fichero del lanzador, pero me pone el lanzador con error, como 
>>> no ejecutable.
>>> 
>>> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
>>> ejecutar el lanzador automáticamente se ejecute con otro usuario, es decir, 
>>> como "root"?
>>
>>¿Has probado lo que recomiendan en el enlace?
>>
>>Comprueba que tienes todos los paquetes necesarios instalados.
>>
>>How to Install Zenmap on Ubuntu 22.04
>>https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/
>>
>>Y revisa los comentarios donde dicen que NO funciona con Python3.
>>
>>Saludos,
>>
>
>Camaleón, ese enlace ya lo había revisado, y me daba problemas de dependencias 
>al instalar la librería que proponen en el proceso, el tema de la instalación 
>de GTK, creo recordar.
>
>Finalmente di con este enlace, que coge el código fuente, hace una 
>modificación de "path" en los ficheros y se hace la compilación e instalación.
>
>Sí ejecuto "sudo zenmap" desde un terminal, "zenmap" arranca en entorno 
>gráfico sin problemas. La historia está en crear un lanzador en el Entorno 
>Gráfico, que no consigo crear el lanzador para que me ejecute "sudo zenmap". 
>También he probado con "pkexec zenmap", pero me da error el lanzador, pero si 
>ejecuto esa orden desde un terminal, funciona perfectamente.
>
>No sé si me explico...
>
>
>Saludos y gracias 
>

Perdón, se me pasó poner el enlace:

https://askubuntu.com/questions/1421263/cant-install-zenmap-on-ubuntu-22-04-due-to-dependency-issues


Saludos y gracias

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 11:53:03 CEST, "Camaleón"  escribió:
>El 2023-03-30 a las 11:33 +0200, Ramses escribió:
>> El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  
>> escribió:
>> >El 2023-03-29 a las 22:00 +0200, Ramses escribió:
>> >
>> >> Tengo estos dos lanzadores en mi Escritorio:
>> >
>> >(...)
>> >
>> >> [Desktop Entry]
>> >(...)
>> >> Exec=zenmap %F
>> >
>> >> [Desktop Entry]
>> >(...)
>> >> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>> >> 
>> >> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando 
>> >> ejecutar el programa con un usuario que no tiene permisos, y a 
>> >> continuación me lo abre.
>> >> 
>> >> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>> >> 
>> >> Si en un terminal ejecuto esta línea 
>> >> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, pero 
>> >> si en el terminal le antepongo el "sudo" a esa línea "sudo 
>> >> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
>> >> 
>> >> He probado a ponerles "sudo" al principio de las lineas en los comandos 
>> >> de los lanzadores, pero me da error.
>> >
>> >Se trata de un bug conocido del paquete que además ya no lo veo 
>> >disponible en las nuevas versiones de Debian:
>> >
>> >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
>> > 
>> >> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute 
>> >> como root?
>> >
>> >Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
>> >necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
>> >aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
>> >actuales de Debian ya no se usan (están policykit, pkexec y demás 
>> >moderneces).
>> >
>> >En cualquier caso, siempre podrás create un nuevo lanzador que se 
>> >ajuste a lo que tengas instalado, según la versión de Debian que 
>> >tengas.
>> >
>> >Mira a ver si te sirve lo que indican por aquí:
>> >
>> >Zenmap (as root) not working on Manjaro
>> >https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
>> >
>> Buenos días,
>> 
>> Ya había probado a anteponer el comando "pkexec" a la línea del comando 
>> editando el fichero del lanzador, pero me pone el lanzador con error, como 
>> no ejecutable.
>> 
>> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
>> ejecutar el lanzador automáticamente se ejecute con otro usuario, es decir, 
>> como "root"?
>
>¿Has probado lo que recomiendan en el enlace?
>
>Comprueba que tienes todos los paquetes necesarios instalados.
>
>How to Install Zenmap on Ubuntu 22.04
>https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/
>
>Y revisa los comentarios donde dicen que NO funciona con Python3.
>
>Saludos,
>

Camaleón, ese enlace ya lo había revisado, y me daba problemas de dependencias 
al instalar la librería que proponen en el proceso, el tema de la instalación 
de GTK, creo recordar.

Finalmente di con este enlace, que coge el código fuente, hace una modificación 
de "path" en los ficheros y se hace la compilación e instalación.

Sí ejecuto "sudo zenmap" desde un terminal, "zenmap" arranca en entorno gráfico 
sin problemas. La historia está en crear un lanzador en el Entorno Gráfico, que 
no consigo crear el lanzador para que me ejecute "sudo zenmap". También he 
probado con "pkexec zenmap", pero me da error el lanzador, pero si ejecuto esa 
orden desde un terminal, funciona perfectamente.

No sé si me explico...


Saludos y gracias 

Re: Crear lanzadores con permisos de superusuario.

[Camaleón]

El 2023-03-30 a las 11:33 +0200, Ramses escribió:
> El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  escribió:
> >El 2023-03-29 a las 22:00 +0200, Ramses escribió:
> >
> >> Tengo estos dos lanzadores en mi Escritorio:
> >
> >(...)
> >
> >> [Desktop Entry]
> >(...)
> >> Exec=zenmap %F
> >
> >> [Desktop Entry]
> >(...)
> >> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> >> 
> >> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando 
> >> ejecutar el programa con un usuario que no tiene permisos, y a 
> >> continuación me lo abre.
> >> 
> >> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> >> 
> >> Si en un terminal ejecuto esta línea 
> >> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, pero 
> >> si en el terminal le antepongo el "sudo" a esa línea "sudo 
> >> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
> >> 
> >> He probado a ponerles "sudo" al principio de las lineas en los comandos de 
> >> los lanzadores, pero me da error.
> >
> >Se trata de un bug conocido del paquete que además ya no lo veo 
> >disponible en las nuevas versiones de Debian:
> >
> >https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
> > 
> >> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute 
> >> como root?
> >
> >Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
> >necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
> >aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
> >actuales de Debian ya no se usan (están policykit, pkexec y demás 
> >moderneces).
> >
> >En cualquier caso, siempre podrás create un nuevo lanzador que se 
> >ajuste a lo que tengas instalado, según la versión de Debian que 
> >tengas.
> >
> >Mira a ver si te sirve lo que indican por aquí:
> >
> >Zenmap (as root) not working on Manjaro
> >https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
> >
> Buenos días,
> 
> Ya había probado a anteponer el comando "pkexec" a la línea del comando 
> editando el fichero del lanzador, pero me pone el lanzador con error, como no 
> ejecutable.
> 
> ¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
> ejecutar el lanzador automáticamente se ejecute con otro usuario, es decir, 
> como "root"?

¿Has probado lo que recomiendan en el enlace?

Comprueba que tienes todos los paquetes necesarios instalados.

How to Install Zenmap on Ubuntu 22.04
https://blog.eldernode.com/install-zenmap-on-ubuntu-22-04/

Y revisa los comentarios donde dicen que NO funciona con Python3.

Saludos,

-- 
Camaleón 

Re: Crear lanzadores con permisos de superusuario.

[Ramses]

El 30 de marzo de 2023 8:21:40 CEST, "Camaleón"  escribió:
>El 2023-03-29 a las 22:00 +0200, Ramses escribió:
>
>> Tengo estos dos lanzadores en mi Escritorio:
>
>(...)
>
>> [Desktop Entry]
>(...)
>> Exec=zenmap %F
>
>> [Desktop Entry]
>(...)
>> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
>> 
>> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando ejecutar 
>> el programa con un usuario que no tiene permisos, y a continuación me lo 
>> abre.
>> 
>> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
>> 
>> Si en un terminal ejecuto esta línea 
>> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, pero si 
>> en el terminal le antepongo el "sudo" a esa línea "sudo 
>> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
>> 
>> He probado a ponerles "sudo" al principio de las lineas en los comandos de 
>> los lanzadores, pero me da error.
>
>Se trata de un bug conocido del paquete que además ya no lo veo 
>disponible en las nuevas versiones de Debian:
>
>https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
> 
>> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute como 
>> root?
>
>Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
>necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
>aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
>actuales de Debian ya no se usan (están policykit, pkexec y demás 
>moderneces).
>
>En cualquier caso, siempre podrás create un nuevo lanzador que se 
>ajuste a lo que tengas instalado, según la versión de Debian que 
>tengas.
>
>Mira a ver si te sirve lo que indican por aquí:
>
>Zenmap (as root) not working on Manjaro
>https://github.com/nmap/nmap/issues/1874#issuecomment-770532361
>
>Saludos,
>

Buenos días,

Ya había probado a anteponer el comando "pkexec" a la línea del comando 
editando el fichero del lanzador, pero me pone el lanzador con error, como no 
ejecutable.

¿Alguna otra idea, incluir "zenmap" en"sudo" de alguna forma para que al 
ejecutar el lanzador automáticamente se ejecute con otro usuario, es decir, 
como "root"?


Saludos y gracias 

Re: Crear lanzadores con permisos de superusuario.

[Camaleón]

El 2023-03-29 a las 22:00 +0200, Ramses escribió:

> Tengo estos dos lanzadores en mi Escritorio:

(...)

> [Desktop Entry]
(...)
> Exec=zenmap %F

> [Desktop Entry]
(...)
> Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
> 
> Si ejecuto el primero "Name=Zenmap", me dice que se está intentando ejecutar 
> el programa con un usuario que no tiene permisos, y a continuación me lo abre.
> 
> Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.
> 
> Si en un terminal ejecuto esta línea 
> "/usr/local/share/zenmap/su-to-zenmap.sh" del segundo, no hace nada, pero si 
> en el terminal le antepongo el "sudo" a esa línea "sudo 
> /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.
> 
> He probado a ponerles "sudo" al principio de las lineas en los comandos de 
> los lanzadores, pero me da error.

Se trata de un bug conocido del paquete que además ya no lo veo 
disponible en las nuevas versiones de Debian:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=zenmap;dist=unstable
 
> ¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute como 
> root?

Leyendo en contenido del guión que ejecuta zenmap como root, veo que 
necesita gksu/kdesu/xterm (?), mira a ver tienes alguna de las 3
aplicaciones pero ya te adelanto que son MUY antiguas, en las versiones 
actuales de Debian ya no se usan (están policykit, pkexec y demás 
moderneces).

En cualquier caso, siempre podrás create un nuevo lanzador que se 
ajuste a lo que tengas instalado, según la versión de Debian que 
tengas.

Mira a ver si te sirve lo que indican por aquí:

Zenmap (as root) not working on Manjaro
https://github.com/nmap/nmap/issues/1874#issuecomment-770532361

Saludos,

-- 
Camaleón 

Crear lanzadores con permisos de superusuario.

[Ramses]

Hola a tod@s,

Tengo estos dos lanzadores en mi Escritorio:

[Desktop Entry]
Name=Zenmap
GenericName=GUI Port Scanner
TryExec=zenmap
Exec=zenmap %F
Terminal=false
Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
Type=Application
Categories=Application;Network;Security;
Comment=A cross-platform GUI for the Nmap Security Scanner.
Keywords=network;scan;scanner;IP;security;


[Desktop Entry]
Name=Zenmap (as root)
GenericName=GUI Port Scanner
TryExec=/usr/local/share/zenmap/su-to-zenmap.sh
Exec=/usr/local/share/zenmap/su-to-zenmap.sh %F
Terminal=false
Icon=/usr/local/share/zenmap/pixmaps/zenmap.png
Type=Application
Categories=Application;Network;Security;
Comment=A cross-platform GUI for the Nmap Security Scanner.
Keywords=network;scan;scanner;IP;security;

Si ejecuto el primero "Name=Zenmap", me dice que se está intentando ejecutar el 
programa con un usuario que no tiene permisos, y a continuación me lo abre.

Si ejecuto el segundo "Name=Zenmap (as root)", no hace nada.

Si en un terminal ejecuto esta línea "/usr/local/share/zenmap/su-to-zenmap.sh" 
del segundo, no hace nada, pero si en el terminal le antepongo el "sudo" a esa 
línea "sudo /usr/local/share/zenmap/su-to-zenmap.sh", se abre sin problemas.

He probado a ponerles "sudo" al principio de las lineas en los comandos de los 
lanzadores, pero me da error.

¿Alguna ayuda de cómo modificar loas lanzadores para que me los ejecute como 
root?


Saludos y gracias

Re: Permisos a directorios en Debian 9

[Galvatorix Torixgalva]

Buenas,

a ver si esta buscando ayuda no empieces con un "Vas muerto" que le vas
a meter el susto en el cuerpo xD

al tema: lo que planteas es un problema porque funcionara cuando funcione y
como funcione, es lo que tiene tener windows de por medio.

Algo que podrias probar es alguna opcion tipo servidor cloud local, como
por ejemplo https://owncloud.org/  pero existen varias opciones. De esta
forma podria ser que evitaras el problema del sistema de archivos tanto de
origen como de destino.

Un saludo




Libre
de virus. www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Permisos a directorios en Debian 9

[Debian]

El 26/9/19 a las 11:05, Centro Patrimonio Pinar del Río escribió:
Hola lista, uso debian 9 cinnamon. Tengo varios usuarios que trabajan en 
la misma estación de trabajo que dispone de particiones ntfs (por 
motivos de trabajo) Alguien puede pasarme alguna *interfaz gráfica* para 
dar permisos de escritura-lectura, etc de mis usuarios ...  o sea que el 
usuario pepe no pueda acceder a una carpeta ej. *inventarios* que 
pertenece a lola ... Cualquier otra sugerencia será válida ...


Saludos ...




Vas muerto.

Lo único que podés hacer sobre una partición ntfs es dar permiso de 
montaje de la unidad.

Una vez montada, el usuario que la monta tiene acceso a TODO.
El problema es que los permisos de carpetas y archivos en Linux son MUY 
distintos a Windows.


Por eso, lo ideal es usar nfs.
Windows puede acceder a nfs, si el disco está en un sistema GNU/Linux y 
compartido, y viceversa, en Windows puedes montar nfs para acceder desde 
Linux. O desde CUALQUIER otro s/o.


Pero hay que dejar de pensar en "máquina que comparte un recurso" y 
pasar a "entorno de red".


Salvo que te la ingenies para que a través de bash en el 
~./.bash_profile de cada usuario le montes sólo la carpeta a la que 
deben acceder.


JAP

Permisos a directorios en Debian 9

[Centro Patrimonio Pinar del Río]

Hola lista, uso debian 9 cinnamon. Tengo varios usuarios que trabajan en 
la misma estación de trabajo que dispone de particiones ntfs (por 
motivos de trabajo) Alguien puede pasarme alguna *interfaz gráfica* para 
dar permisos de escritura-lectura, etc de mis usuarios ...  o sea que el 
usuario pepe no pueda acceder a una carpeta ej. *inventarios* que 
pertenece a lola ... Cualquier otra sugerencia será válida ...


Saludos ...

Re: configuración de permisos predeterminados (umask) para nuevos usuarios.

[Fran Torres]

Buenas,

NO, no he querido usar owncloud, pues más o menos quise basarme en lo
que hemos estudiado en clase y owncloud a parte que no lo hemos tocado
(y dudo que lo hagamos), no es accesible.

Fran.

El 14/11/18, Galvatorix Torixgalva  escribió:
> Hola,
>
> una cosilla... has pensado en usar owncloud?. Puede que te sirva.
>
> P. D: juro que se me acaba de ocurrir hace 5 minutos
>
> Saludos
>

Re: configuración de permisos predeterminados (umask) para nuevos usuarios.

[Galvatorix Torixgalva]

Hola,

una cosilla... has pensado en usar owncloud?. Puede que te sirva.

P. D: juro que se me acaba de ocurrir hace 5 minutos

Saludos

RE: configuración de permisos predeterminados (umask) para nuevos usuarios.

[ziprasidone146939277]

> Buenas,

Buenas, reenvío a la lista.

> Gracias. De todas formas, ya está solucionado. No, no me interesaba que
> cada usuario tubiera su propio home; si no que, compartiesen todos un solo
> home que, en este caso es:
> /srv/ftp.
> la carpeta ftp, pertenece al grupo ftp, con permisos 2770 (rwxrwxs---).
> y de paso se le ha añadido el stickibit (rwxrwxs-wxt).
> de modo que queda así:
> d-rwxrws-wt.
> Para lo del umask, he editado el fichero (/etc/login.defs), como sugirieron
> por aquí.
>   Y como servidor ftp, estoy usando proftpd; para que coja los usuarios, lo
> tengo configurado para que los coja del fichero /etc/passwd Como dige
> anteriormente en el primer mail, el fichero /etc/default/useradd está
> también editado, de modo que los usuarios por defecto tengan los siguientes
> parámetros:
> home: /srv/ftp
> shell: /bin/ghost (shell que obviamente me he sacado de la patilla y no vale
> para nada)
> group: 1001

Me alegro que hayas podido solucionarlo.

Pienso que cuando tienes que "meter tanta mano" o modificar tantos archivos del 
s.o. (que por lo general muy poco frecuente se modifican) para levantar un 
servicio, puede que algo no ande bien o no estés usando la solución/software 
adecuado.

Tu necesidad/caso aplica más a un servidor de archivos y no a un FTP.
Como quiera que sea, si lo pudiste resolver y funciona, no hay más que decir.

Un saludo

RE: configuración de permisos predeterminados (umask) para nuevos usuarios.

[ziprasidone146939277]

> estoy tratando de configurar un servidor FTP con varios usuarios (sí, ya lo 
> sé,
> es lo más inseguro que existe pero, cumple con las necesidades para lo que
> se le necesita).

No sé si te servirá o aplicara a tu caso (omito el tema de los permisos que 
necesitas), *pero*:

Cuando tienes un servidor FTP con varios usuarios, "lo normal" es que cada uno 
tenga su propio home. 
Al menos así lo entiendo yo.

> Alguna idea?

Si, una idea sería usar usuarios "virtuales" con autenticación.

Por ejemplo, si usas vsftpd, sería algo así (va lo relevante):

   guest_username=ftp # todos los usuario se conectan "en realidad" con este 
usuario local.
   local_enable=YES
   chroot_local_user=YES # los enjaulas a cada uno en su propio $HOME.
   local_root=/dir/ftp/$USER # el usuario "usuarioFTP1" solo va a poder 
acceder, leer, escribir ,etc solo y solo en: /dir/ftp/usuarioFTP1 (y no va a 
poder subir de directorio por el chroot)

Luego asignas permisos 700 (o incluso 755) recursivo a /dir/ftp/$USER con 
propietario y grupo ftp. Siempre usuario real "ftp"

i.e.: 
drwxr-xr-x 9 ftp ftp 4096 Jul  4 08:43 .

> Fran.

Por último, dejo un enlace desde el cual más o menos te puedes valer para hacer 
lo que digo: 
https://www.rosehosting.com/blog/easy-ftp-vsftpd-server-with-virtual-users-on-debian-8-jessie/

Saludos

Re: configuración de permisos predeterminados (umask) para nuevos usuarios.

[julher]

El dom, 11-11-2018 a las 23:04 +0100, Fran Torres escribió:
> Buenas,
> 
> julher, estoy haciendo lo que me dices, de modificar /etc/login.defs
> pero, hay dos líneas que no entiendo y que, no sé si pueden afectar a
> la de UMASK, ya que están en su misma sección.
> 
> ERASECHAR 017
> KILLCHAR 025
> UMASK 022

Se trataría de cambiar ese valor de 022 por el que necesites tener, las
otras dos líneas son definiciones de códigos de teclas que no te
afectan y deberías no tocarlas.

> 
> La última la entiendo pero, las otras 2 no.
>   Por otro lado, me dices que a /etc/profile puedo agregarle la línea
> umask xxx. Pero... en que parte de todos los ifs que contiene?
> 

En ninguno, me explico, antes de todos o después de todos, o en
cualquier sitio siempre que no esté dentro de ningún "if". De todos
modos si lo cambias en el /etc/login.defs entiendo que no sería
necesario cambiar el /etc/profile.

Un saludo

JulHer

Re: configuración de permisos predeterminados (umask) para nuevos usuarios.

[Fran Torres]

Buenas,

julher, estoy haciendo lo que me dices, de modificar /etc/login.defs
pero, hay dos líneas que no entiendo y que, no sé si pueden afectar a
la de UMASK, ya que están en su misma sección.

ERASECHAR 017
KILLCHAR 025
UMASK 022

La última la entiendo pero, las otras 2 no.
  Por otro lado, me dices que a /etc/profile puedo agregarle la línea
umask xxx. Pero... en que parte de todos los ifs que contiene?

Fran.


El 11/11/18, jul...@escomposlinux.org  escribió:
> El dom, 11-11-2018 a las 20:48 +0100, Fran Torres escribió:
>> Buenas,
>>
>> estoy tratando de configurar un servidor FTP con varios usuarios (sí,
>> ya lo sé, es lo más inseguro que existe pero, cumple con las
>> necesidades para lo que se le necesita).
>>
>>   Ahora, me encuentro que, a la hora de crear los usuarios con
>> useradd, todos cogen los permisos 022 (644/755) que son los
>> predeterminados de linux. Pero, no quiero utilizar esos permisos si
>> no, predeterminar otros:
>> 047/057 (740/750 si no me equivoco).
>> (RWX/R--/---//RWX/RX/---)
>> de modo que los usuarios nuevos puedan leer, escribir y ejecutar
>> (propietario), leer (no escribir y no ejecutar grupo), y nada el
>> resto. (fichero).
>> Leer, escribir, ejecutar (propietario), leer y ejecutar (grupo), nada
>> el resto (directorios); sin tener que modificar yo los permisos a
>> mano.
>>
>> Leyendo por google, dicen que hay que modificar el fichero
>> /etc/profile pero, este es un script que llama a otros ficheros por
>> lo
>> que, aparentemente no me vale.
>
>>   También mencionan la modificación de los ficheros /etc/bash.bashrc
>> pero, me da a mi que tampoco. Y lo mismo con /.bashrc pero, este es
>> para el usuario actual. por tanto, me vale menos.
>
> Si, si que vale. Habría que añadir una línea con "umask xxx" en esos
> archivos para que los permisos por defecto al crear un achivo sean los
> que te interesen. Lo puedes ver muy bien explicado aquí:
>
> https://wiki.archlinux.org/index.php/Umask_(Espa%C3%B1ol)
>
>
>>
>>   lo que he hecho, ha sido aprovechar el grupo ftp que viene con el
>> sistema, y modificar /etc/default/useradd de la siguiente forma:
>>
>> home: /srv/ftp
>> group: 1001 #gid del grupo ftp.
>> shell: /bin/ghost #shell fantasma
>>
>> En la carpeta /srv, tengo creado el directorio ftp y, le tengo los
>> permisos:
>> rwx/r-s/--- (2770). de modo que, todo lo que se cree dentro, coja los
>> permisos del grupo ftp. que son: rwx/r-x/---).
>>   Y para los ficheros quiero que sea: RWX/R--/---
>>   Lo suyo es, que en el ftp una vez operativo, todo dios pueda crear
>> directorios y ficheros, pero no borrarlos, salvo los suyos propios. Y
>> a la vez, el resto pueda acceder a los ficheros y directorios de
>> todos. NO se si me explico.
>
> Ok.
>
>>   Y la idea, es hacerlo sin necesidad de ir usuario por usuario.
>>   Los usuarios los creo de la siguiente forma:
>> useradd -g ftp -d /srv/ftp -c comentario nombre
>> passwd nombre
>>
>> Alguna idea?
>
> Si, puedes configurar el comando useradd para que al crear los usuarios
> el "umask" sea el que te interese.
>
> Si haces un man useradd verás que es configurable y podrás definir los
> permisos por defecto de todos los archivos que un usuario crea. Busca
> UMASK en el man useradd.
>
> Un saludo
>
> JulHer
>
>>
>> Fran.
>>
>
>

Re: configuración de permisos predeterminados (umask) para nuevos usuarios.

[julher]

El dom, 11-11-2018 a las 20:48 +0100, Fran Torres escribió:
> Buenas,
> 
> estoy tratando de configurar un servidor FTP con varios usuarios (sí,
> ya lo sé, es lo más inseguro que existe pero, cumple con las
> necesidades para lo que se le necesita).
> 
>   Ahora, me encuentro que, a la hora de crear los usuarios con
> useradd, todos cogen los permisos 022 (644/755) que son los
> predeterminados de linux. Pero, no quiero utilizar esos permisos si
> no, predeterminar otros:
> 047/057 (740/750 si no me equivoco).
> (RWX/R--/---//RWX/RX/---)
> de modo que los usuarios nuevos puedan leer, escribir y ejecutar
> (propietario), leer (no escribir y no ejecutar grupo), y nada el
> resto. (fichero).
> Leer, escribir, ejecutar (propietario), leer y ejecutar (grupo), nada
> el resto (directorios); sin tener que modificar yo los permisos a
> mano.
> 
> Leyendo por google, dicen que hay que modificar el fichero
> /etc/profile pero, este es un script que llama a otros ficheros por
> lo
> que, aparentemente no me vale.

>   También mencionan la modificación de los ficheros /etc/bash.bashrc
> pero, me da a mi que tampoco. Y lo mismo con /.bashrc pero, este es
> para el usuario actual. por tanto, me vale menos.

Si, si que vale. Habría que añadir una línea con "umask xxx" en esos
archivos para que los permisos por defecto al crear un achivo sean los
que te interesen. Lo puedes ver muy bien explicado aquí:

https://wiki.archlinux.org/index.php/Umask_(Espa%C3%B1ol)


> 
>   lo que he hecho, ha sido aprovechar el grupo ftp que viene con el
> sistema, y modificar /etc/default/useradd de la siguiente forma:
> 
> home: /srv/ftp
> group: 1001 #gid del grupo ftp.
> shell: /bin/ghost #shell fantasma
> 
> En la carpeta /srv, tengo creado el directorio ftp y, le tengo los
> permisos:
> rwx/r-s/--- (2770). de modo que, todo lo que se cree dentro, coja los
> permisos del grupo ftp. que son: rwx/r-x/---).
>   Y para los ficheros quiero que sea: RWX/R--/---
>   Lo suyo es, que en el ftp una vez operativo, todo dios pueda crear
> directorios y ficheros, pero no borrarlos, salvo los suyos propios. Y
> a la vez, el resto pueda acceder a los ficheros y directorios de
> todos. NO se si me explico.

Ok.

>   Y la idea, es hacerlo sin necesidad de ir usuario por usuario.
>   Los usuarios los creo de la siguiente forma:
> useradd -g ftp -d /srv/ftp -c comentario nombre
> passwd nombre
> 
> Alguna idea?

Si, puedes configurar el comando useradd para que al crear los usuarios
el "umask" sea el que te interese.

Si haces un man useradd verás que es configurable y podrás definir los
permisos por defecto de todos los archivos que un usuario crea. Busca
UMASK en el man useradd.

Un saludo

JulHer
 
> 
> Fran.
> 

configuración de permisos predeterminados (umask) para nuevos usuarios.

[Fran Torres]

Buenas,

estoy tratando de configurar un servidor FTP con varios usuarios (sí,
ya lo sé, es lo más inseguro que existe pero, cumple con las
necesidades para lo que se le necesita).

  Ahora, me encuentro que, a la hora de crear los usuarios con
useradd, todos cogen los permisos 022 (644/755) que son los
predeterminados de linux. Pero, no quiero utilizar esos permisos si
no, predeterminar otros:
047/057 (740/750 si no me equivoco).
(RWX/R--/---//RWX/RX/---)
de modo que los usuarios nuevos puedan leer, escribir y ejecutar
(propietario), leer (no escribir y no ejecutar grupo), y nada el
resto. (fichero).
Leer, escribir, ejecutar (propietario), leer y ejecutar (grupo), nada
el resto (directorios); sin tener que modificar yo los permisos a
mano.

Leyendo por google, dicen que hay que modificar el fichero
/etc/profile pero, este es un script que llama a otros ficheros por lo
que, aparentemente no me vale.
  También mencionan la modificación de los ficheros /etc/bash.bashrc
pero, me da a mi que tampoco. Y lo mismo con /.bashrc pero, este es
para el usuario actual. por tanto, me vale menos.

  lo que he hecho, ha sido aprovechar el grupo ftp que viene con el
sistema, y modificar /etc/default/useradd de la siguiente forma:

home: /srv/ftp
group: 1001 #gid del grupo ftp.
shell: /bin/ghost #shell fantasma

En la carpeta /srv, tengo creado el directorio ftp y, le tengo los permisos:
rwx/r-s/--- (2770). de modo que, todo lo que se cree dentro, coja los
permisos del grupo ftp. que son: rwx/r-x/---).
  Y para los ficheros quiero que sea: RWX/R--/---
  Lo suyo es, que en el ftp una vez operativo, todo dios pueda crear
directorios y ficheros, pero no borrarlos, salvo los suyos propios. Y
a la vez, el resto pueda acceder a los ficheros y directorios de
todos. NO se si me explico.
  Y la idea, es hacerlo sin necesidad de ir usuario por usuario.
  Los usuarios los creo de la siguiente forma:
useradd -g ftp -d /srv/ftp -c comentario nombre
passwd nombre

Alguna idea?

Fran.

Re: Problemas de permisos en samba

[Fernando Romero]

El 31 de julio de 2018, 12:08, Raimundo Baravaglio <
rbaravag...@blgnet.com.ar> escribió:

> Ejemplo de configuración para cada carpeta:
> 
>
> [Tu_Carpeta_Compartida]
> comment = Carpeta Compartida
> path = /home/carpetacompartida
> browseable = yes
> force user = tu_nombre_de_usuario
> force group = carpetacompartidacontodos
> create mode = 660
> directory mode = 770
> read only = no
> guest ok = no
> writeable = yes
> valid users = @carpetacompartidacontodos
>
> 
>
> Para que esto funcione, tendrás que agregar a todos los usuarios (a los
> que quieras dar permiso de acceso a una carpeta determinada) a un grupo
> determinado (en el ejemplo:  "carpetacompartidacontodos")
>
> Eso se hace desde consola con los comandos:
>
>
>1. sudo groupadd carpetacompartidacontodos (esto agrega el nuevo grupo
>al sistema)
>2. sudo usermod -g carpetacompartidacontodos nombre_del_usuario_que_se_
>agrega_al_grupo
>
>
> Después, tenés que nombrar desde el sistema a ese grupo como propietario
> de la carpeta con:
>
> sudo chown -R usuario_propietario_de_la_carpeta:carpetacompartidacontodos
> carpetacompartidacontodos
>
> El comando chown modifica al propietario de una carpeta determinada y
> también al grupo propietario. La opción "-R" (en mayúsculas) hace que
> abarque todo lo que está en su interior, tanto carpetas como archivos, para
> darles propiedad sobre los mismos con el mismo usuario y grupo.
>
> Una última aclaración: Es necesario que cada usuario tenga (además de su
> clave del sistema Linux) una clave de acceso para SAMBA. Para esto es
> necesario que el usuario se agregue al sistema SAMBA mediante el siguiente
> comando:
>
> *smbpasswd –a nombre_del_usuario*
>
> Con eso tendría que funcionarte todo sin problemas.
>
> Saludos!
>
>
>
> *Raimundo Baravaglio*
>
> *Dto. Sistemas*
> Talcahuano 355 - Villa Martelli
> <https://maps.google.com/?q=Talcahuano+355+-+Villa+Martelli+Provincia+de+Bs.+As=gmail=g>
> Provincia de Bs. As
> <https://maps.google.com/?q=Talcahuano+355+-+Villa+Martelli+Provincia+de+Bs.+As=gmail=g>.
>
> Tel: (011) 4709-0053
> Móvil: (+54 9) 1153754068
> Web: www.blgnet.com.ar
>
>
> *Aviso legal: *
>
> *Esta información, privada y confidencial, está dirigida únicamente a su
> destinatario.*
>
> *Si usted no es el destinatario de este mensaje, se le notifica que
> cualquier difusión, distribución o copia de este mensaje (o una porción de
> él) está estrictamente prohibido.**Legal warning:*
> *This information, private and confidential, is addressed only to the
> recipient.*
> *If you are not the intended recipient of this message **you are hereby
> notified that any distribution or copying of this message **(or a portion
> of it) is strictly prohibited.*
>
>
>
> El vie., 20 jul. 2018 a las 22:16, Fernando Romero (<
> ffrcaraba...@gmail.com>) escribió:
>
>> Configure para compartir un directorio en samba y lo puedo mapear y ver
>> desde Windows pero no puedo hacer que tenga permisos de escritura.
>> Esta es la conf del smb.conf
>>
>> [global]
>> workgroup = WORKGROUP
>> server string = %h server
>> log file = /var/log/samba/log.%m
>> max log size = 1000
>> syslog = 0
>> panic action = /usr/share/samba/panic-action %d
>> security = user
>> encrypt passwords = true
>> passdb backend = tdbsam
>> obey pam restrictions = yes
>> unix password sync = yes
>> passwd program = /usr/bin/passwd %u
>> passwd chat = *Enter\snew\s*\spassword:* %n\n
>>  *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>> pam password change = yes
>> map to guest = bad user
>> usershare allow guests = yes
>>
>> [Fileserver]
>> comment = Fileserver
>> public = yes
>> read only = no
>> writable = yes
>> path = /home/file
>> guest ok = yes
>> browseable = yes
>> create mode = 0777
>> directory mode = 0777
>>
>> Al directorio que estoy compartiendo le di los permisos 755.
>> Que me esta faltando?
>>
>> Saludos y gracias
>>
>
Muchas gracias Raimundo.

Saludos

Re: Problemas de permisos en samba

[Fernando Romero]

El lun., jul. 23, 2018 9:17, Matias Mucciolo 
escribió:

>
> On Saturday, July 21, 2018 1:31:47 PM -03 Fernando Romero wrote:
> > El sáb., jul. 21, 2018 13:08, Galvatorix Torixgalva <
> >
> > galvatorix2...@gmail.com> escribió:
> > > Hola,
> > >
> > > has comprobado los permisos de cada usuario?.
> > >
> > > Yo empezaria con 777 para comprobar que esta todo bien.
> > >
> > > Un saludo
> >
> > Los usuarios son invitados no se loguean
>
> Buenas
> si ... falta darle permisos de escritura a "TODOS"
> es decir chmod 777 /home/file (o la carpeta correcta)
>
> después tendras que ver los subdirectorios y los  files en si...
> que seria 666 para archivos..
>
> saludos.
> Matias
>

Gracias matias mañana voy a hacer eso.

Saludos

>

Re: Problemas de permisos en samba

[Matias Mucciolo]

On Saturday, July 21, 2018 1:31:47 PM -03 Fernando Romero wrote:
> El sáb., jul. 21, 2018 13:08, Galvatorix Torixgalva <
> 
> galvatorix2...@gmail.com> escribió:
> > Hola,
> > 
> > has comprobado los permisos de cada usuario?.
> > 
> > Yo empezaria con 777 para comprobar que esta todo bien.
> > 
> > Un saludo
> 
> Los usuarios son invitados no se loguean

Buenas
si ... falta darle permisos de escritura a "TODOS"
es decir chmod 777 /home/file (o la carpeta correcta)

después tendras que ver los subdirectorios y los  files en si...
que seria 666 para archivos..

saludos.
Matias.

Re: Problemas de permisos en samba

[Fernando Romero]

El sáb., jul. 21, 2018 16:07, Felix Perez 
escribió:

> 2018-07-21 12:20 GMT-04:00 Fernando Romero :
> >
> >
> > El sáb., jul. 21, 2018 13:16, Felix Perez 
> > escribió:
> >>
> >> 2018-07-20 21:16 GMT-04:00 Fernando Romero :
> >> > Configure para compartir un directorio en samba y lo puedo mapear y
> ver
> >> > desde Windows pero no puedo hacer que tenga permisos de escritura.
> >> > Esta es la conf del smb.conf
> >>
> >> Qué windows?
> >> En que entorno de red windows?
> >>
> >> >
> >> > [global]
> >> > workgroup = WORKGROUP
> >> > server string = %h server
> >> > log file = /var/log/samba/log.%m
> >> > max log size = 1000
> >> > syslog = 0
> >> > panic action = /usr/share/samba/panic-action %d
> >> > security = user
> >> > encrypt passwords = true
> >> > passdb backend = tdbsam
> >> > obey pam restrictions = yes
> >> > unix password sync = yes
> >> > passwd program = /usr/bin/passwd %u
> >> > passwd chat = *Enter\snew\s*\spassword:* %n\n
> >> >  *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
> >> > pam password change = yes
> >> > map to guest = bad user
> >> > usershare allow guests = yes
> >> >
> >> > [Fileserver]
> >> > comment = Fileserver
> >> > public = yes
> >> > read only = no
> >> > writable = yes
> >> > path = /home/file
> >> > guest ok = yes
> >> > browseable = yes
> >> > create mode = 0777
> >> > directory mode = 0777
> >> >
> >> > Al directorio que estoy compartiendo le di los permisos 755.
> >> > Que me esta faltando?
> >> >
> >> > Saludos y gracias
> >>
> >>
> >>
> >> --
> >
> >
> > Las pc qie se conectan al compartido son windows eso quise decir
>
> Si eso se entiende, yo pregunto ¿que versión de windows? ¿AD o grupo
> de trabajo o grupos de win10? Se comportan de manera diferente.
>
> Saludos.
>
> >
> > Saludos
> >
> >>
> >
>
>
>
> --
> usuario linux  #274354
> normas de la lista:  http://wiki.debian.org/es/NormasLista
> como hacer preguntas inteligentes:
> http://www.sindominio.net/ayuda/preguntas-inteligentes.htm
> <http://www.sindominio.net/ayuda/preguntas-inteligentes.html>


El samba no lo uni al AD y las pc estan en un AD del 2013

>
>

Re: Problemas de permisos en samba

[Felix Perez]

2018-07-21 12:20 GMT-04:00 Fernando Romero :
>
>
> El sáb., jul. 21, 2018 13:16, Felix Perez 
> escribió:
>>
>> 2018-07-20 21:16 GMT-04:00 Fernando Romero :
>> > Configure para compartir un directorio en samba y lo puedo mapear y ver
>> > desde Windows pero no puedo hacer que tenga permisos de escritura.
>> > Esta es la conf del smb.conf
>>
>> Qué windows?
>> En que entorno de red windows?
>>
>> >
>> > [global]
>> > workgroup = WORKGROUP
>> > server string = %h server
>> > log file = /var/log/samba/log.%m
>> > max log size = 1000
>> > syslog = 0
>> > panic action = /usr/share/samba/panic-action %d
>> > security = user
>> > encrypt passwords = true
>> > passdb backend = tdbsam
>> > obey pam restrictions = yes
>> > unix password sync = yes
>> > passwd program = /usr/bin/passwd %u
>> > passwd chat = *Enter\snew\s*\spassword:* %n\n
>> >  *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>> > pam password change = yes
>> > map to guest = bad user
>> > usershare allow guests = yes
>> >
>> > [Fileserver]
>> > comment = Fileserver
>> > public = yes
>> > read only = no
>> > writable = yes
>> > path = /home/file
>> > guest ok = yes
>> > browseable = yes
>> > create mode = 0777
>> > directory mode = 0777
>> >
>> > Al directorio que estoy compartiendo le di los permisos 755.
>> > Que me esta faltando?
>> >
>> > Saludos y gracias
>>
>>
>>
>> --
>
>
> Las pc qie se conectan al compartido son windows eso quise decir

Si eso se entiende, yo pregunto ¿que versión de windows? ¿AD o grupo
de trabajo o grupos de win10? Se comportan de manera diferente.

Saludos.

>
> Saludos
>
>>
>



-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: Problemas de permisos en samba

[Fernando Romero]

El sáb., jul. 21, 2018 13:08, Galvatorix Torixgalva <
galvatorix2...@gmail.com> escribió:

> Hola,
>
> has comprobado los permisos de cada usuario?.
>
> Yo empezaria con 777 para comprobar que esta todo bien.
>
> Un saludo
>

Los usuarios son invitados no se loguean

Re: Problemas de permisos en samba

[Fernando Romero]

El sáb., jul. 21, 2018 13:16, Felix Perez 
escribió:

> 2018-07-20 21:16 GMT-04:00 Fernando Romero :
> > Configure para compartir un directorio en samba y lo puedo mapear y ver
> > desde Windows pero no puedo hacer que tenga permisos de escritura.
> > Esta es la conf del smb.conf
>
> Qué windows?
> En que entorno de red windows?
>
> >
> > [global]
> > workgroup = WORKGROUP
> > server string = %h server
> > log file = /var/log/samba/log.%m
> > max log size = 1000
> > syslog = 0
> > panic action = /usr/share/samba/panic-action %d
> > security = user
> > encrypt passwords = true
> > passdb backend = tdbsam
> > obey pam restrictions = yes
> > unix password sync = yes
> > passwd program = /usr/bin/passwd %u
> > passwd chat = *Enter\snew\s*\spassword:* %n\n
> >  *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
> > pam password change = yes
> > map to guest = bad user
> > usershare allow guests = yes
> >
> > [Fileserver]
> > comment = Fileserver
> > public = yes
> > read only = no
> > writable = yes
> >     path = /home/file
> > guest ok = yes
> > browseable = yes
> > create mode = 0777
> > directory mode = 0777
> >
> > Al directorio que estoy compartiendo le di los permisos 755.
> > Que me esta faltando?
> >
> > Saludos y gracias
>
>
>
> --
> usuario linux  #274354
> normas de la lista:  http://wiki.debian.org/es/NormasLista
> como hacer preguntas inteligentes:
> http://www.sindominio.net/ayuda/preguntas-inteligentes.html


Las pc qie se conectan al compartido son windows eso quise decir

Saludos


>

Re: Problemas de permisos en samba

[Felix Perez]

2018-07-20 21:16 GMT-04:00 Fernando Romero :
> Configure para compartir un directorio en samba y lo puedo mapear y ver
> desde Windows pero no puedo hacer que tenga permisos de escritura.
> Esta es la conf del smb.conf

Qué windows?
En que entorno de red windows?

>
> [global]
> workgroup = WORKGROUP
> server string = %h server
> log file = /var/log/samba/log.%m
> max log size = 1000
> syslog = 0
> panic action = /usr/share/samba/panic-action %d
> security = user
> encrypt passwords = true
> passdb backend = tdbsam
> obey pam restrictions = yes
> unix password sync = yes
> passwd program = /usr/bin/passwd %u
> passwd chat = *Enter\snew\s*\spassword:* %n\n
>  *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
> pam password change = yes
> map to guest = bad user
> usershare allow guests = yes
>
> [Fileserver]
> comment = Fileserver
> public = yes
> read only = no
> writable = yes
> path = /home/file
> guest ok = yes
> browseable = yes
> create mode = 0777
> directory mode = 0777
>
> Al directorio que estoy compartiendo le di los permisos 755.
> Que me esta faltando?
>
> Saludos y gracias



-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: Problemas de permisos en samba

[Galvatorix Torixgalva]

Hola,

has comprobado los permisos de cada usuario?.

Yo empezaria con 777 para comprobar que esta todo bien.

Un saludo

Problemas de permisos en samba

[Fernando Romero]

Configure para compartir un directorio en samba y lo puedo mapear y ver
desde Windows pero no puedo hacer que tenga permisos de escritura.
Esta es la conf del smb.conf

[global]
workgroup = WORKGROUP
server string = %h server
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n
 *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes

[Fileserver]
comment = Fileserver
public = yes
read only = no
writable = yes
path = /home/file
guest ok = yes
browseable = yes
create mode = 0777
directory mode = 0777

Al directorio que estoy compartiendo le di los permisos 755.
Que me esta faltando?

Saludos y gracias

Re: Tengo un problema de permisos

[divagante]

El 23/10/17 a las 15:06, Joaquín Sanchís Robles escribió:
> Cuando pongo el usb supuestamente el usuario no tiene permisos en la
> carpeta /media
> ¿Cómo hago para tener permisos?
> Gracias de antemano

Que version de debian estas usando? a mi hasta la 8/jessie no me daba
problemas, pero recuerdo que alguna vez padeci lo mismo, quizas con la
7/wheezy.
 No estoy usando la 9/streech.

Tengo un problema de permisos

[Joaquín Sanchís Robles]

Cuando pongo el usb supuestamente el usuario no tiene permisos en la
carpeta /media
¿Cómo hago para tener permisos?
Gracias de antemano

Re: Cambiar permisos a memoria externa (USB)

[Ángel]

Lo más probable es que el sistema de ficheros presentara algún error, y
el kernel lo remontara automáticamente como solo lectura.
Normalmente con desconectarla y reconectarla ya funcionan. De todos
modos, deberías hacerle un fsck para comprobar el estado de los
ficheros.

Sobre la fecha dic 31  1969, la cámara debe haber creado los ficheros
con "fecha 0" (el epoch UNIX, 1 de enero de 1970). Ahora bien, los
sistemas de archivos FAT (FAT16, FAT32, etc) almacenan la fecha en hora
local, al hacer las conversiones de zona horaria, ha pasado «al día
anterior».

Finalmente, si se trata de un sistema de archivos FAT, no se le puede
cambiar los permisos ni el propietario al contenido, porque
directamente, el sistema de ficheros no lo soporta (el propietario que
muestra es uno que toma a la hora de montar el sistema de archivos, que
aplica a todo el contenido del disco).

Un saludo

Fwd: Re: Cambiar permisos a memoria externa (USB)

[Raúl Armenta]

-- Mensaje reenviado --
De: "Darío" <dario...@openmailbox.org>
Fecha: 5 jul. 2017 19:20
Asunto: Re: Cambiar permisos a memoria externa (USB)
Para: <debian-user-spanish@lists.debian.org>
Cc:

El 05/07/2017 02:01 PM, claudio menet escribió:

> Darío,
>
> Si es una tarjeta SD puede ser que esté protegida físicamente.
>
> Algunas tarjetas SD traer una pequeña palanca que al moverla, a veces
> sin quererlo, protege contra escritura la memoria.
>
> Saludos
>

Sí corroboré eso, pero las compactflash no tienen esa traba (las SD sí),
tampoco lo tiene la lectora.
Sin embargo! acabo de cambiar conectándola en el otro puerto y ahora lee y
escribe, incluso copiando y pegando con el botón derecho de la notebook,
sin necesidad de ser root.
Muy raro?! siempre pude copiar, pegar y borrar datos de esa memoria.
El comando ls -ltr sigue dando exactamente lo mismo

drwx--  4 darioslc darioslc 32768 dic 31  1969 EOS_DIGITAL

un poco raro que en el año 69 haya cámaras digitales que usaran tarjetas CF
inventadas más de veinte años después.







Yo creo que esa tarjeta pasó a mejor vida.


Raúl Armenta.

Re: Cambiar permisos a memoria externa (USB)

[Darío]

El 05/07/2017 02:01 PM, claudio menet escribió:

Darío,

Si es una tarjeta SD puede ser que esté protegida físicamente.

Algunas tarjetas SD traer una pequeña palanca que al moverla, a veces
sin quererlo, protege contra escritura la memoria.

Saludos


Sí corroboré eso, pero las compactflash no tienen esa traba (las SD sí), 
tampoco lo tiene la lectora.
Sin embargo! acabo de cambiar conectándola en el otro puerto y ahora lee 
y escribe, incluso copiando y pegando con el botón derecho de la 
notebook, sin necesidad de ser root.

Muy raro?! siempre pude copiar, pegar y borrar datos de esa memoria.
El comando ls -ltr sigue dando exactamente lo mismo

drwx--  4 darioslc darioslc 32768 dic 31  1969 EOS_DIGITAL

un poco raro que en el año 69 haya cámaras digitales que usaran tarjetas 
CF inventadas más de veinte años después.

Re: Cambiar permisos a memoria externa (USB)

[claudio menet]

Darío,

Si es una tarjeta SD puede ser que esté protegida físicamente.

Algunas tarjetas SD traer una pequeña palanca que al moverla, a veces
sin quererlo, protege contra escritura la memoria.

Saludos

El día 5 de julio de 2017, 13:48, Darío <dario...@openmailbox.org> escribió:
> El 05/07/2017 01:29 PM, claudio menet escribió:
>>
>> Hola Dario,
>>
>> "chmod +x" Se utiliza para hacer un fichero ejecutable
>>
>> Yo antes de aplicar algún permiso haría un ls -ltr sobre el directorio
>> para ver que usuario y grupo tiene permisos sobre los mismos y que
>> permisos tienen.
>>
>> En este link podes obtener información de cómo funcionan los permisos
>> en gnu-linux
>
>
> Efectivamente, sólo puede acceder el dueño del dispositivo (soy yo pero no
> lo soy jaja):
> ls -ltr /media/darioslc/
> total 40
> drwxrwxrwx 25 root root  4096 abr 26  2015
> 76a5a70f-6da7-4ac2-b5d3-8a19ca87124c
> drwxrwxrwx 22 root root  4096 oct  7  2016
> 7434e569-5480-47c3-b852-de17765ae1c0
> drwx--  4 darioslc darioslc 32768 jul  5 10:55 EOS_DIGITAL
>
> las dos primeras corresponden a otras particiones del disco, y la tercera al
> dispositivo al que le quiero copiar archivos, recuerdo que con chmod 777 -R
> /dirección cambiaba los permisos para que tanto dueño, grupo y otros
> pudieran ejecutar, leer y escribir, pero me da el error:
>
> chmod: cambiando los permisos de «/media/darioslc/EOS_DIGITAL/MISC»: Sistema
> de ficheros de sólo lectura
>
> Me extraña que siendo root tampoco pueda copiar otros archivos
> El sistema se monta automático al conectar el USB.
>

Re: Cambiar permisos a memoria externa (USB)

[Darío]

El 05/07/2017 01:29 PM, claudio menet escribió:

Hola Dario,

"chmod +x" Se utiliza para hacer un fichero ejecutable

Yo antes de aplicar algún permiso haría un ls -ltr sobre el directorio
para ver que usuario y grupo tiene permisos sobre los mismos y que
permisos tienen.

En este link podes obtener información de cómo funcionan los permisos
en gnu-linux


Efectivamente, sólo puede acceder el dueño del dispositivo (soy yo pero 
no lo soy jaja):

ls -ltr /media/darioslc/
total 40
drwxrwxrwx 25 root root  4096 abr 26  2015 
76a5a70f-6da7-4ac2-b5d3-8a19ca87124c
drwxrwxrwx 22 root root  4096 oct  7  2016 
7434e569-5480-47c3-b852-de17765ae1c0

drwx--  4 darioslc darioslc 32768 jul  5 10:55 EOS_DIGITAL

las dos primeras corresponden a otras particiones del disco, y la 
tercera al dispositivo al que le quiero copiar archivos, recuerdo que 
con chmod 777 -R /dirección cambiaba los permisos para que tanto dueño, 
grupo y otros pudieran ejecutar, leer y escribir, pero me da el error:


chmod: cambiando los permisos de «/media/darioslc/EOS_DIGITAL/MISC»: 
Sistema de ficheros de sólo lectura


Me extraña que siendo root tampoco pueda copiar otros archivos
El sistema se monta automático al conectar el USB.

Re: Cambiar permisos a memoria externa (USB)

[Alfonso Camacho]

Saludos:

> Buenas! estoy teniendo problemas para copiar unos archivos a una memoria
> externa (tarjeta compact flash (CF) que uso como pendrive). Los archivos
> los tengo en el disco rígido y no me da la opción con botón derecho
> sobre la carpeta de la CF.
> Entonces abrí una consola root para cambiarle los permisos:
> chmod +x -R /media/
> 
> luego de un rato tira a cada uno de los archivos dentro:
> Sistema de ficheros de solo lectura
> 
> y tampoco puedo copiar un archivo siendo root
> "No se puede crear el fichero regular «/media/archivo»: Sistema de
> ficheros de sólo lectura"
> 
> ¿Cómo hago para cambiar estos permisos?
> 

Si se trata de un dispositivo externo en algún momento se tiene que montar en 
el sistema.

Al hacer el mount se le puede pasar los permisos que quieres que tenga ese 
dispositivo por defecto:

# mount -t deviceFileFormat -o 
umask=filePermissons,gid=ownerGroupID,uid=ownerID /device /mountpoint



-- 
Alfonso <alfo...@gnuino.net>

Re: Cambiar permisos a memoria externa (USB)

[claudio menet]

Hola Dario,

"chmod +x" Se utiliza para hacer un fichero ejecutable

Yo antes de aplicar algún permiso haría un ls -ltr sobre el directorio
para ver que usuario y grupo tiene permisos sobre los mismos y que
permisos tienen.

En este link podes obtener información de cómo funcionan los permisos
en gnu-linux

https://debian-handbook.info/browse/es-ES/stable/sect.rights-management.html

Saludos!

El día 5 de julio de 2017, 13:17, Darío <dario...@openmailbox.org> escribió:
> Buenas! estoy teniendo problemas para copiar unos archivos a una memoria
> externa (tarjeta compact flash (CF) que uso como pendrive). Los archivos los
> tengo en el disco rígido y no me da la opción con botón derecho sobre la
> carpeta de la CF.
> Entonces abrí una consola root para cambiarle los permisos:
> chmod +x -R /media/
>
> luego de un rato tira a cada uno de los archivos dentro:
> Sistema de ficheros de solo lectura
>
> y tampoco puedo copiar un archivo siendo root
> "No se puede crear el fichero regular «/media/archivo»: Sistema de ficheros
> de sólo lectura"
>
> ¿Cómo hago para cambiar estos permisos?
>
> Gracias!
> Darío
>

Cambiar permisos a memoria externa (USB)

[Darío]

Buenas! estoy teniendo problemas para copiar unos archivos a una memoria 
externa (tarjeta compact flash (CF) que uso como pendrive). Los archivos 
los tengo en el disco rígido y no me da la opción con botón derecho 
sobre la carpeta de la CF.

Entonces abrí una consola root para cambiarle los permisos:
chmod +x -R /media/

luego de un rato tira a cada uno de los archivos dentro:
Sistema de ficheros de solo lectura

y tampoco puedo copiar un archivo siendo root
"No se puede crear el fichero regular «/media/archivo»: Sistema de 
ficheros de sólo lectura"


¿Cómo hago para cambiar estos permisos?

Gracias!
Darío

[OT] Samba 4 + permisos en copia.

[Laotrasolucion]

Hola,

Tengo un pequeño problema con un samba 4 que esta como fileserver. Me
pasa que cuando algún usuario mueve o copia un archivo de una carpeta a
otra el archivo en cuestión queda como "read-only". Desde la consola lo
veo al atributo RDONLY y desde windows tiene marcado el atributo solo
lectura, esto genera que no pueda manipular archivo al cual el usuario
es el owner

3879 11124  DENY_NONE  0x120089RDONLYEXCLUSIVE+BATCH
 /USUARIOS   planilla/Cartas/161107.ods   Wed Nov 16 14:11:48 2016


Para el permiso de los usuarios estoy usando ACL tal como explica la
pagina de samba.
https://wiki.samba.org/index.php/Shares_with_Windows_ACLs


getfacl: Eliminando '/' inicial en nombres de ruta absolutos
# file: USUARIOS/planilla/Cartas/161107.ods
# owner: josela
# group: domain\040users
user::rwx
user:domain\040admins:rwx
user:josela:rwx
user:grp_users:r--
user:grp_nexx:rwx
user:grp_usersnexx:r-x
user:grp_nexx_gerencia:rwx
group::---
group:domain\040admins:rwx
group:domain\040users:---
group:grp_usersnexx:r--
group:grp_users:r-x
group:grp_NEXX_gerencia:rwx
mask::rwx
other::---



la configuración del samba es la siguiente:

[global]
security = ADS
workgroup = NEXX
realm = NEXX.LAN
netbios name = sambafs
encrypt passwords = yes

vfs objects = acl_xattr full_audit

full_audit:prefix = %u|%I|%m|%S
full_audit:success = mkdir rename unlink rmdir pwrite
full_audit:failure = none
full_audit:facility = local7
full_audit:priority = NOTICE


map acl inherit = Yes
store dos attributes = Yes
log level = 3
winbind trusted domains only = no
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind offline logon = yes
winbind refresh tickets = yes

idmap config *:range = 2000-
idmap config NEXX:backend = rid
idmap config NEXX:schema_mode = rfc2307
idmap config NEXX:range = 1-9
winbind nss info = rfc2307


printcap name = /dev/null
load printers = no





[usuarios]
path = /USUARIOS
read only = no




signature.asc
Description: OpenPGP digital signature

Re: Permisos para crear fichero PID

[Camaleón]

El Thu, 26 Nov 2015 22:07:41 +0100, Josu Lazkano escribió:

> El día 26 de noviembre de 2015, 22:04, Josu Lazkano
> <josu.lazk...@gmail.com> escribió:
>> El día 25 de noviembre de 2015, 15:56, Camaleón <noela...@gmail.com>
>> escribió:

(...)

>>> Ejecuta los comandos que indican "systemctl status
>>> mythtv-backend.service"
>>> y "journalctl -xn" para ver más detalles.
>>>
>>> Aunque parecen dos problemas distintos porque en este caso no has
>>> cambiado manualmente ninguna configuración y usas la que viene de
>>> serie, en el caso de MythTV sí dicen expresamente que hay que tener en
>>> cuenta cuando se usa con systemd:
>>>
>>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>>
>>> Y revisa también la configuración inicial por si te faltara algo:
>>>
>>> https://www.mythtv.org/wiki/User_Manual:Initial_Installation
>>>
> 
> Perdona, que he enviado sin querer.
> 
> Esto es lo que tengo:
> 
> # /etc/init.d/mythtv-backend start [] Starting mythtv-backend (via
> systemctl):
> mythtv-backend.serviceJob for mythtv-backend.service failed. See
> 'systemctl status mythtv-backend.service' and 'journalctl -xn' for
> details.
>  failed!
> 
> # systemctl status mythtv-backend.service ● mythtv-backend.service -
> LSB: Start/Stop the MythTV server.
>Loaded: loaded (/etc/init.d/mythtv-backend)
>Active: failed (Result: exit-code) since Thu 2015-11-26 22:02:40 CET;
>9s ago
>   Process: 2924 ExecStart=/etc/init.d/mythtv-backend start
> (code=exited, status=136)

No entiendo por qué usa "/etc/init.d/" si el sistema tiene systemd. 
¿Acaso MythTV no usa de manera nativa systemd? :-?

(...)

> Nov 26 22:02:40 mitxetv mythtv-backend[2924]: eno: Permission denied
> (13)

(...)

> # chmod 755 /var/run/mythtv/
> 
> # /etc/init.d/mythtv-backend start [ ok ] Starting mythtv-backend (via
> systemctl): mythtv-backend.service.

Sí, esta claro que parece un problema con los permisos del directorio 
pero eso debe de hacerlo el script automáticamente, tú no deberías de 
editar nada. No sé, podría ser un bug, considera informar de esto el D-M, 
al fin y al cabo el paquete lo crean ellos.

> Segun leo en la wiki, necesitaria añadir esto en
> /etc/init.d/mythtv-backend?
> 
> # Sanity check on required folders if [ ! -x /var/log/mythtv ]; then #
> make logging folder mkdir -p -m 755 /var/log/mythtv chown -hR
> mythtv:mythtv /var/log/mythtv fi # make pid folder mkdir -p -m 755
> /run/mythtv chown -hR mythtv:mythtv /run/mythtv
> 
> No entiendo muy bien porque dejo de fallar de un momento a otro.

Porque los permisos del directorio "/run" los gestiona systemd (euid 0) 
cuando está habilitado. Ahora bien, no me termina de convencer que tengas 
que definir manualmente los permisos de ese directorio para que funcione 
la aplicación, eso no es normal, algo falla ahí.

Saludos,

-- 
Camaleón

Re: Permisos para crear fichero PID

[Josu Lazkano]

Gracias a todos por vuestra ayuda.

Lo he soluciona añadiendo "mkdir -p -m 755 $RUNDIR" en el
/etc/init.d./mythtv-backend

Un saludo.


-- 
Josu Lazkano

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Camaleón]

El Thu, 26 Nov 2015 19:29:08 +0100, Maykel Franco escribió:

¡Grrr..!

> El 26 nov. 2015 7:26 p. m., "Camaleón"  escribió:

(...)

>> > Los usuarios están añadidos al grupo www-data. Es lo raro de todo
>> > esto que así no funcione.
>>
>> Prueba con "directory mask = 0775"
>>
>> ¿Y te pasa con todos los archivos o sólo tienes problemas con los PSD y
>> Photoshop?
>>
> Sólo con esos archivos. De todas formas lo pruebo porque es de lo que se
> han quejado los diseñadorcitos...

Pues parece que es un problema de MacOS y/o Photoshop, o al menos eso es 
lo que apunta Google:

https://www.google.com/webhp?complete=0=en_rd=cr,ssl#complete=0=en=samba+share+save+psd+fails

Revisa los mensajes de los foros a ver si encuentras algo útil, por 
ejemplo:

Photoshop CS6 on OSX using SMB shares
https://community.spiceworks.com/topic/439375-photoshop-cs6-on-osx-using-smb-shares

Saludos,

-- 
Camaleón

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Camaleón]

El Wed, 25 Nov 2015 17:22:49 +0100, Maykel Franco escribió:

> El día 25 de noviembre de 2015, 17:15, Ariel Alvarez
>  escribió:
>> yo en mi caso uso samba3 aun no me he decidido a migrar mi pdc a
>> samba4, en mi caso tengo mapeado por asi decirlo el directorio que le
>> corresponde a mi usuario el el explorador de windows ejemplo :
>> ariel(\\PDC) (U:) por lo que tome un PSD cualquiera y lo copie en ese
>> directorio el cual apunta al servidor linux con samba3, acto seguido
>> fui a ese directorio y me abrio perfectamente probe ambas posibilidades
>> doble clic en el archivo y clic derecho abrir con, todo sin problemas.

> Gracias por las pruebas Ariel. No lo he comentado pero es un Mac...p

¿Has probado lo que te comenté? Es decir, a abrir el PSD con otra 
aplicación. 

También podrías intentar a abrir el archivo desde Photoshop (Menú → 
Archivo → Abrir...).

Saludos,

-- 
Camaleón

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Maykel Franco]

El día 26 de noviembre de 2015, 15:50, Camaleón <noela...@gmail.com> escribió:
> El Wed, 25 Nov 2015 17:22:49 +0100, Maykel Franco escribió:
>
>> El día 25 de noviembre de 2015, 17:15, Ariel Alvarez
>> <ar...@cncc.cult.cu> escribió:
>>> yo en mi caso uso samba3 aun no me he decidido a migrar mi pdc a
>>> samba4, en mi caso tengo mapeado por asi decirlo el directorio que le
>>> corresponde a mi usuario el el explorador de windows ejemplo :
>>> ariel(\\PDC) (U:) por lo que tome un PSD cualquiera y lo copie en ese
>>> directorio el cual apunta al servidor linux con samba3, acto seguido
>>> fui a ese directorio y me abrio perfectamente probe ambas posibilidades
>>> doble clic en el archivo y clic derecho abrir con, todo sin problemas.
>
>> Gracias por las pruebas Ariel. No lo he comentado pero es un Mac...p
>
> ¿Has probado lo que te comenté? Es decir, a abrir el PSD con otra
> aplicación.
>
> También podrías intentar a abrir el archivo desde Photoshop (Menú →
> Archivo → Abrir...).
>
> Saludos,
>
> --
> Camaleón
>

Si, ahora resulta que me dice que abrirlo si puede abrirlo, el
problema es al guardarlo... Si no lo ha creado él, no le deja
guardarlo con el mismo nombre ni con otro nombre... Si lo ha creado
él, le permite editarlo sin problemas y crear un nuevo fichero a
partir de ese con otro nombre...

Los permisos los tengo en la carpeta como www-data.www-data, y digo
por qué, porque también quieren acceder via owncloud. Entonces me
visto obligado a darle permisos recursivos de www-data.www-data y
meter a los usuarios dentro del grupo www-data.

Por otro lado, he ajustado la configuración de samba para forzarle en
los permisos que los genere con el nombre del usuario grupo www-data
así:

[TEST]
  comment = Diseno Owncloud
  path = /path/a/la/ruta
  valid users = test
  force group = www-data
  create mask = 0660
  directory mask = 0771
  writable = yes
  browseable = yes

Así lo tengo...

Los permisos cuando se crean ficheros un usuario se queda así:

rw-rw 1 test www-data 17737014 nov 26 16:27 fichero.psd

Y los directorios:

drwxrwx--x 2 test www-data 6 nov 26 16:37 test

Gracias.

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Camaleón]

El Thu, 26 Nov 2015 16:38:16 +0100, Maykel Franco escribió:

> El día 26 de noviembre de 2015, 15:50, Camaleón <noela...@gmail.com>
> escribió:

(...)

>> ¿Has probado lo que te comenté? Es decir, a abrir el PSD con otra
>> aplicación.
>>
>> También podrías intentar a abrir el archivo desde Photoshop (Menú →
>> Archivo → Abrir...).
>>
>>
> Si, ahora resulta que me dice que abrirlo si puede abrirlo, el problema
> es al guardarlo... Si no lo ha creado él, no le deja guardarlo con el
> mismo nombre ni con otro nombre... Si lo ha creado él, le permite
> editarlo sin problemas y crear un nuevo fichero a partir de ese con otro
> nombre...

Ya me parecía raro que el mensaje le dijera "guardar" ;-)

> Los permisos los tengo en la carpeta como www-data.www-data, y digo por
> qué, porque también quieren acceder via owncloud. Entonces me visto
> obligado a darle permisos recursivos de www-data.www-data y meter a los
> usuarios dentro del grupo www-data.

Sí, si creo que ya hemos hablado de esto varias veces en la lista.

> Por otro lado, he ajustado la configuración de samba para forzarle en
> los permisos que los genere con el nombre del usuario grupo www-data
> así:
> 
> [TEST]
>   comment = Diseno Owncloud path = /path/a/la/ruta valid users = test
>   force group = www-data create mask = 0660 directory mask = 0771
>   writable = yes browseable = yes
> 
> Así lo tengo...
> 
> Los permisos cuando se crean ficheros un usuario se queda así:
> 
> rw-rw 1 test www-data 17737014 nov 26 16:27 fichero.psd

Con esos permisos sólo el usuario "test" y el grupo "www-data" pueden 
sobreescribir el archivo.

> Y los directorios:
> 
> drwxrwx--x 2 test www-data 6 nov 26 16:37 test
> 
> Gracias.

Aquí lo mismo, estás limitando demasiado el acceso a los usuarios 
particulares y eso con samba es complicado, si no usas ACL funciona mejor 
añadiendo a los usuarios al mismo grupo de acceso genérico ("samba", 
etc...). 

¿Por qué no añades a los usuarios al grupo "www-data" o no te fías 
demasiado?

Saludos,

-- 
Camaleón

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Maykel Franco]

El 26 nov. 2015 6:03 p. m., "Camaleón" <noela...@gmail.com> escribió:
>
> El Thu, 26 Nov 2015 16:38:16 +0100, Maykel Franco escribió:
>
> > El día 26 de noviembre de 2015, 15:50, Camaleón <noela...@gmail.com>
> > escribió:
>
> (...)
>
> >> ¿Has probado lo que te comenté? Es decir, a abrir el PSD con otra
> >> aplicación.
> >>
> >> También podrías intentar a abrir el archivo desde Photoshop (Menú →
> >> Archivo → Abrir...).
> >>
> >>
> > Si, ahora resulta que me dice que abrirlo si puede abrirlo, el problema
> > es al guardarlo... Si no lo ha creado él, no le deja guardarlo con el
> > mismo nombre ni con otro nombre... Si lo ha creado él, le permite
> > editarlo sin problemas y crear un nuevo fichero a partir de ese con otro
> > nombre...
>
> Ya me parecía raro que el mensaje le dijera "guardar" ;-)
>
> > Los permisos los tengo en la carpeta como www-data.www-data, y digo por
> > qué, porque también quieren acceder via owncloud. Entonces me visto
> > obligado a darle permisos recursivos de www-data.www-data y meter a los
> > usuarios dentro del grupo www-data.
>
> Sí, si creo que ya hemos hablado de esto varias veces en la lista.
>
> > Por otro lado, he ajustado la configuración de samba para forzarle en
> > los permisos que los genere con el nombre del usuario grupo www-data
> > así:
> >
> > [TEST]
> >   comment = Diseno Owncloud path = /path/a/la/ruta valid users = test
> >   force group = www-data create mask = 0660 directory mask = 0771
> >   writable = yes browseable = yes
> >
> > Así lo tengo...
> >
> > Los permisos cuando se crean ficheros un usuario se queda así:
> >
> > rw-rw 1 test www-data 17737014 nov 26 16:27 fichero.psd
>
> Con esos permisos sólo el usuario "test" y el grupo "www-data" pueden
> sobreescribir el archivo.
>
> > Y los directorios:
> >
> > drwxrwx--x 2 test www-data 6 nov 26 16:37 test
> >
> > Gracias.
>
> Aquí lo mismo, estás limitando demasiado el acceso a los usuarios
> particulares y eso con samba es complicado, si no usas ACL funciona mejor
> añadiendo a los usuarios al mismo grupo de acceso genérico ("samba",
> etc...).
>
> ¿Por qué no añades a los usuarios al grupo "www-data" o no te fías
> demasiado?

Los usuarios están añadidos al grupo www-data. Es lo raro de todo esto que
así no funcione.

>
> Saludos,
>
> --
> Camaleón
>

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Camaleón]

El Thu, 26 Nov 2015 19:13:48 +0100, Maykel Franco escribió:

(¬__¬)

> El 26 nov. 2015 6:03 p. m., "Camaleón" <noela...@gmail.com> escribió:

(...)

>> > [TEST]
>> >   comment = Diseno Owncloud path = /path/a/la/ruta valid users = test
>> >   force group = www-data create mask = 0660 directory mask = 0771
>> >   writable = yes browseable = yes
>> >
>> > Así lo tengo...
>> >
>> > Los permisos cuando se crean ficheros un usuario se queda así:
>> >
>> > rw-rw 1 test www-data 17737014 nov 26 16:27 fichero.psd
>>
>> Con esos permisos sólo el usuario "test" y el grupo "www-data" pueden
>> sobreescribir el archivo.
>>
>> > Y los directorios:
>> >
>> > drwxrwx--x 2 test www-data 6 nov 26 16:37 test
>> >
>> > Gracias.
>>
>> Aquí lo mismo, estás limitando demasiado el acceso a los usuarios
>> particulares y eso con samba es complicado, si no usas ACL funciona
>> mejor añadiendo a los usuarios al mismo grupo de acceso genérico
>> ("samba", etc...).
>>
>> ¿Por qué no añades a los usuarios al grupo "www-data" o no te fías
>> demasiado?
> 
> Los usuarios están añadidos al grupo www-data. Es lo raro de todo esto
> que así no funcione.

Prueba con "directory mask = 0775"

¿Y te pasa con todos los archivos o sólo tienes problemas con los PSD y 
Photoshop?

Saludos,

-- 
Camaleón

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Maykel Franco]

El 26 nov. 2015 7:26 p. m., "Camaleón" <noela...@gmail.com> escribió:
>
> El Thu, 26 Nov 2015 19:13:48 +0100, Maykel Franco escribió:
>
> (¬__¬)
>
> > El 26 nov. 2015 6:03 p. m., "Camaleón" <noela...@gmail.com> escribió:
>
> (...)
>
> >> > [TEST]
> >> >   comment = Diseno Owncloud path = /path/a/la/ruta valid users = test
> >> >   force group = www-data create mask = 0660 directory mask = 0771
> >> >   writable = yes browseable = yes
> >> >
> >> > Así lo tengo...
> >> >
> >> > Los permisos cuando se crean ficheros un usuario se queda así:
> >> >
> >> > rw-rw 1 test www-data 17737014 nov 26 16:27 fichero.psd
> >>
> >> Con esos permisos sólo el usuario "test" y el grupo "www-data" pueden
> >> sobreescribir el archivo.
> >>
> >> > Y los directorios:
> >> >
> >> > drwxrwx--x 2 test www-data 6 nov 26 16:37 test
> >> >
> >> > Gracias.
> >>
> >> Aquí lo mismo, estás limitando demasiado el acceso a los usuarios
> >> particulares y eso con samba es complicado, si no usas ACL funciona
> >> mejor añadiendo a los usuarios al mismo grupo de acceso genérico
> >> ("samba", etc...).
> >>
> >> ¿Por qué no añades a los usuarios al grupo "www-data" o no te fías
> >> demasiado?
> >
> > Los usuarios están añadidos al grupo www-data. Es lo raro de todo esto
> > que así no funcione.
>
> Prueba con "directory mask = 0775"
>
> ¿Y te pasa con todos los archivos o sólo tienes problemas con los PSD y
> Photoshop?
>
> Saludos,
>
> --
> Camaleón
>

Sólo con esos archivos. De todas formas lo pruebo porque es de lo que se
han quejado los diseñadorcitos...

Re: Permisos para crear fichero PID

[Josu Lazkano]

El día 26 de noviembre de 2015, 22:04, Josu Lazkano
<josu.lazk...@gmail.com> escribió:
> El día 25 de noviembre de 2015, 15:56, Camaleón <noela...@gmail.com> escribió:
>> El Tue, 24 Nov 2015 22:25:07 +0100, Josu Lazkano escribió:
>>
>>> El día 10 de noviembre de 2015, 16:03, Camaleón <noela...@gmail.com>
>>> escribió:
>>
>> (...)
>>
>>>>> Originalmente el PID se gaurdaba en
>>>>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>>>>> no se si importa.
>>>>>
>>>>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>>>
>>>> Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo?
>>>>
>>>> Vuelve a dejarlo como estaba y si funciona seguramente sea porque el
>>>> directorio donde se guardaba el PID del servicio tenía los permisos
>>>> adecuados para que el usuario "debian-transmission" tuviera acceso de
>>>> escritura en él.
>>>>
>>>> Por otra parte no dices si usas sysvinit o systemd y eso puede marcar
>>>> una diferencia.
>>>>
>>>>
>>> Hola de nuevo y gracias por responder,
>>>
>>> Creo que utilizo el systemd, tengo el que viene por defecto con Debian
>>> Jessie.
>>
>> Ok.
>>
>>> Me acabo de dar cuenta que tambien me pasa con otro servicio. Y es a
>>> raiz de alguna actualizacion, no se exactamente cual. Antes no tenia
>>> este problema.
>>>
>>> El servicio mythbackend tampoco puedo ejecutarlo:
>>>
>>> root@server:~# ls -al /var/run/mythtv/
>>> total 0 drw-r-xr-x  2 mythtv root  40 Nov 24 17:54 .
>>> drwxr-xr-x 25 root   root 880 Nov 24 17:54 ..
>>> root@server:~# /etc/init.d/mythtv-backend start [] Starting
>>> mythtv-backend (via systemctl):
>>> mythtv-backend.serviceJob for mythtv-backend.service failed. See
>>> 'systemctl status mythtv-backend.service' and 'journalctl -xn' for
>>> details.
>>>  failed!
>>
>> (...)
>>
>> Ejecuta los comandos que indican "systemctl status mythtv-backend.service"
>> y "journalctl -xn" para ver más detalles.
>>
>> Aunque parecen dos problemas distintos porque en este caso no has
>> cambiado manualmente ninguna configuración y usas la que viene de serie,
>> en el caso de MythTV sí dicen expresamente que hay que tener en cuenta
>> cuando se usa con systemd:
>>
>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>
>> Y revisa también la configuración inicial por si te faltara algo:
>>
>> https://www.mythtv.org/wiki/User_Manual:Initial_Installation
>>
>> Saludos,
>>
>> --
>> Camaleón
>>
>
> Gracias por contestar Camaleon,
>
> Esto es lo que tengo:
>
>
> --
> Josu Lazkano

Perdona, que he enviado sin querer.

Esto es lo que tengo:

# /etc/init.d/mythtv-backend start
[] Starting mythtv-backend (via systemctl):
mythtv-backend.serviceJob for mythtv-backend.service failed. See
'systemctl status mythtv-backend.service' and 'journalctl -xn' for
details.
 failed!

# systemctl status mythtv-backend.service
● mythtv-backend.service - LSB: Start/Stop the MythTV server.
   Loaded: loaded (/etc/init.d/mythtv-backend)
   Active: failed (Result: exit-code) since Thu 2015-11-26 22:02:40 CET; 9s ago
  Process: 2924 ExecStart=/etc/init.d/mythtv-backend start
(code=exited, status=136)

Nov 26 22:02:40 mitxetv mythtv-backend[2924]: Starting MythTV server: mythba...:
Nov 26 22:02:40 mitxetv mythtv-backend[2924]: eno: Permission denied (13)
Nov 26 22:02:40 mitxetv systemd[1]: mythtv-backend.service: control process...36
Nov 26 22:02:40 mitxetv systemd[1]: Failed to start LSB: Start/Stop the Myt.
Nov 26 22:02:40 mitxetv systemd[1]: Unit mythtv-backend.service entered fai...e.
Hint: Some lines were ellipsized, use -l to show in full.

# chmod 755 /var/run/mythtv/

# /etc/init.d/mythtv-backend start
[ ok ] Starting mythtv-backend (via systemctl): mythtv-backend.service.

Segun leo en la wiki, necesitaria añadir esto en /etc/init.d/mythtv-backend?

# Sanity check on required folders
if [ ! -x /var/log/mythtv ]; then
# make logging folder
mkdir -p -m 755 /var/log/mythtv
chown -hR mythtv:mythtv /var/log/mythtv
fi
# make pid folder
mkdir -p -m 755 /run/mythtv
chown -hR mythtv:mythtv /run/mythtv

No entiendo muy bien porque dejo de fallar de un momento a otro.

Gracias y saludos.


-- 
Josu Lazkano

Re: Permisos para crear fichero PID

[Josu Lazkano]

El día 25 de noviembre de 2015, 15:56, Camaleón <noela...@gmail.com> escribió:
> El Tue, 24 Nov 2015 22:25:07 +0100, Josu Lazkano escribió:
>
>> El día 10 de noviembre de 2015, 16:03, Camaleón <noela...@gmail.com>
>> escribió:
>
> (...)
>
>>>> Originalmente el PID se gaurdaba en
>>>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>>>> no se si importa.
>>>>
>>>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>>
>>> Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo?
>>>
>>> Vuelve a dejarlo como estaba y si funciona seguramente sea porque el
>>> directorio donde se guardaba el PID del servicio tenía los permisos
>>> adecuados para que el usuario "debian-transmission" tuviera acceso de
>>> escritura en él.
>>>
>>> Por otra parte no dices si usas sysvinit o systemd y eso puede marcar
>>> una diferencia.
>>>
>>>
>> Hola de nuevo y gracias por responder,
>>
>> Creo que utilizo el systemd, tengo el que viene por defecto con Debian
>> Jessie.
>
> Ok.
>
>> Me acabo de dar cuenta que tambien me pasa con otro servicio. Y es a
>> raiz de alguna actualizacion, no se exactamente cual. Antes no tenia
>> este problema.
>>
>> El servicio mythbackend tampoco puedo ejecutarlo:
>>
>> root@server:~# ls -al /var/run/mythtv/
>> total 0 drw-r-xr-x  2 mythtv root  40 Nov 24 17:54 .
>> drwxr-xr-x 25 root   root 880 Nov 24 17:54 ..
>> root@server:~# /etc/init.d/mythtv-backend start [] Starting
>> mythtv-backend (via systemctl):
>> mythtv-backend.serviceJob for mythtv-backend.service failed. See
>> 'systemctl status mythtv-backend.service' and 'journalctl -xn' for
>> details.
>>  failed!
>
> (...)
>
> Ejecuta los comandos que indican "systemctl status mythtv-backend.service"
> y "journalctl -xn" para ver más detalles.
>
> Aunque parecen dos problemas distintos porque en este caso no has
> cambiado manualmente ninguna configuración y usas la que viene de serie,
> en el caso de MythTV sí dicen expresamente que hay que tener en cuenta
> cuando se usa con systemd:
>
> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>
> Y revisa también la configuración inicial por si te faltara algo:
>
> https://www.mythtv.org/wiki/User_Manual:Initial_Installation
>
> Saludos,
>
> --
> Camaleón
>

Gracias por contestar Camaleon,

Esto es lo que tengo:


-- 
Josu Lazkano

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Ariel Alvarez]

yo en mi caso uso samba3 aun no me he decidido a migrar mi pdc a samba4, 
en mi caso tengo mapeado por asi decirlo el directorio que le 
corresponde a mi usuario el el explorador de windows ejemplo : 
ariel(\\PDC) (U:) por lo que tome un PSD cualquiera y lo copie en ese 
directorio el cual apunta al servidor linux con samba3, acto seguido fui 
a ese directorio y me abrio perfectamente probe ambas posibilidades 
doble clic en el archivo y clic derecho abrir con, todo sin problemas.


El 25/11/2015 10:15, Camaleón escribió:

El Wed, 25 Nov 2015 16:02:31 +0100, Maykel Franco escribió:


Buenas, en donde trabajo tenemos determinados diseñadores que trabajan
con photoshop y algunas herramientas más. Tenemos un samba para que
guarden sus trabajos psd alli y demás. Pueden crear, borrar, etc, pero
lo que no pueden hacer es abrir un psd desde la carpeta compartida
directamente con photoshop, les da error de permisos... He revisado los
permisos de samba de la creación de los ficheros y no tiene ningún
problema. De hecho, por descarte he dado a un fichero psd concreto todos
los permisos y pasa exactamente lo mismo.

http://imgur.com/MmTLKey

¿"Abrir" o "guardar"?

Porque dices "abrir" pero en la imagen pone "guardar".
  

Esto no creo que sea problema de permisos, de samba sino más bien de la
aplicación photoshop, algún fichero temporal que genera o algo así...

Os ha pasado alguno??

Con word, excell, powerpoint, txt...etc no tengo ningún problema.

Gracias de antemano.

Me pasa con ciertos archivos y en un volumen no samba sino nativo de
Windows (es decir, el cliente usa linux y accede a servidores windows).
Por ejemplo, los documentos de MS Office, no hay error pero no se abren
correctamente. Imágenes, texto y PDF se abren sin problemas.

En cambio, la situación que describes no la puedo reproducir (en cliente
windows y servidor samba) un archivo PSD se abre sin problemas con
Fireworks, en este caso. Mira, es verdad... prueba a abrirlo desde otra
aplicación que no sea Adobe Photoshop para descartar o confirmar el
origen del problema.

Saludos,




-
Consejo Nacional de Casas de Cultura
http://www.casasdecultura.cult.cu

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Maykel Franco]

El día 25 de noviembre de 2015, 17:15, Ariel Alvarez
<ar...@cncc.cult.cu> escribió:
> yo en mi caso uso samba3 aun no me he decidido a migrar mi pdc a samba4, en
> mi caso tengo mapeado por asi decirlo el directorio que le corresponde a mi
> usuario el el explorador de windows ejemplo : ariel(\\PDC) (U:) por lo que
> tome un PSD cualquiera y lo copie en ese directorio el cual apunta al
> servidor linux con samba3, acto seguido fui a ese directorio y me abrio
> perfectamente probe ambas posibilidades doble clic en el archivo y clic
> derecho abrir con, todo sin problemas.
>
>
> El 25/11/2015 10:15, Camaleón escribió:
>>
>> El Wed, 25 Nov 2015 16:02:31 +0100, Maykel Franco escribió:
>>
>>> Buenas, en donde trabajo tenemos determinados diseñadores que trabajan
>>> con photoshop y algunas herramientas más. Tenemos un samba para que
>>> guarden sus trabajos psd alli y demás. Pueden crear, borrar, etc, pero
>>> lo que no pueden hacer es abrir un psd desde la carpeta compartida
>>> directamente con photoshop, les da error de permisos... He revisado los
>>> permisos de samba de la creación de los ficheros y no tiene ningún
>>> problema. De hecho, por descarte he dado a un fichero psd concreto todos
>>> los permisos y pasa exactamente lo mismo.
>>>
>>> http://imgur.com/MmTLKey
>>
>> ¿"Abrir" o "guardar"?
>>
>> Porque dices "abrir" pero en la imagen pone "guardar".
>>
>>>
>>> Esto no creo que sea problema de permisos, de samba sino más bien de la
>>> aplicación photoshop, algún fichero temporal que genera o algo así...
>>>
>>> Os ha pasado alguno??
>>>
>>> Con word, excell, powerpoint, txt...etc no tengo ningún problema.
>>>
>>> Gracias de antemano.
>>
>> Me pasa con ciertos archivos y en un volumen no samba sino nativo de
>> Windows (es decir, el cliente usa linux y accede a servidores windows).
>> Por ejemplo, los documentos de MS Office, no hay error pero no se abren
>> correctamente. Imágenes, texto y PDF se abren sin problemas.
>>
>> En cambio, la situación que describes no la puedo reproducir (en cliente
>> windows y servidor samba) un archivo PSD se abre sin problemas con
>> Fireworks, en este caso. Mira, es verdad... prueba a abrirlo desde otra
>> aplicación que no sea Adobe Photoshop para descartar o confirmar el
>> origen del problema.
>>
>> Saludos,
>>
>
>
> -
> Consejo Nacional de Casas de Cultura
> http://www.casasdecultura.cult.cu
>

Gracias por las pruebas Ariel. No lo he comentado pero es un Mac...p

Re: Permisos para crear fichero PID

[Camaleón]

El Tue, 24 Nov 2015 22:25:07 +0100, Josu Lazkano escribió:

> El día 10 de noviembre de 2015, 16:03, Camaleón <noela...@gmail.com>
> escribió:

(...)

>>> Originalmente el PID se gaurdaba en
>>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>>> no se si importa.
>>>
>>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>
>> Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo?
>>
>> Vuelve a dejarlo como estaba y si funciona seguramente sea porque el
>> directorio donde se guardaba el PID del servicio tenía los permisos
>> adecuados para que el usuario "debian-transmission" tuviera acceso de
>> escritura en él.
>>
>> Por otra parte no dices si usas sysvinit o systemd y eso puede marcar
>> una diferencia.
>>
>>
> Hola de nuevo y gracias por responder,
> 
> Creo que utilizo el systemd, tengo el que viene por defecto con Debian
> Jessie.

Ok.

> Me acabo de dar cuenta que tambien me pasa con otro servicio. Y es a
> raiz de alguna actualizacion, no se exactamente cual. Antes no tenia
> este problema.
> 
> El servicio mythbackend tampoco puedo ejecutarlo:
> 
> root@server:~# ls -al /var/run/mythtv/
> total 0 drw-r-xr-x  2 mythtv root  40 Nov 24 17:54 .
> drwxr-xr-x 25 root   root 880 Nov 24 17:54 ..
> root@server:~# /etc/init.d/mythtv-backend start [] Starting
> mythtv-backend (via systemctl):
> mythtv-backend.serviceJob for mythtv-backend.service failed. See
> 'systemctl status mythtv-backend.service' and 'journalctl -xn' for
> details.
>  failed!

(...)

Ejecuta los comandos que indican "systemctl status mythtv-backend.service" 
y "journalctl -xn" para ver más detalles.

Aunque parecen dos problemas distintos porque en este caso no has 
cambiado manualmente ninguna configuración y usas la que viene de serie, 
en el caso de MythTV sí dicen expresamente que hay que tener en cuenta 
cuando se usa con systemd:

https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration

Y revisa también la configuración inicial por si te faltara algo:

https://www.mythtv.org/wiki/User_Manual:Initial_Installation

Saludos,

-- 
Camaleón

[OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Maykel Franco]

Buenas, en donde trabajo tenemos determinados diseñadores que trabajan
con photoshop y algunas herramientas más. Tenemos un samba para que
guarden sus trabajos psd alli y demás. Pueden crear, borrar, etc, pero
lo que no pueden hacer es abrir un psd desde la carpeta compartida
directamente con photoshop, les da error de permisos... He revisado
los permisos de samba de la creación de los ficheros y no tiene ningún
problema. De hecho, por descarte he dado a un fichero psd concreto
todos los permisos y pasa exactamente lo mismo.

http://imgur.com/MmTLKey

Esto no creo que sea problema de permisos, de samba sino más bien de
la aplicación photoshop, algún fichero temporal que genera o algo
así...

Os ha pasado alguno??

Con word, excell, powerpoint, txt...etc no tengo ningún problema.

Gracias de antemano.

Re: [OT] Samba - Problema de permisos con photoshop abrir documento desde la red

[Camaleón]

El Wed, 25 Nov 2015 16:02:31 +0100, Maykel Franco escribió:

> Buenas, en donde trabajo tenemos determinados diseñadores que trabajan
> con photoshop y algunas herramientas más. Tenemos un samba para que
> guarden sus trabajos psd alli y demás. Pueden crear, borrar, etc, pero
> lo que no pueden hacer es abrir un psd desde la carpeta compartida
> directamente con photoshop, les da error de permisos... He revisado los
> permisos de samba de la creación de los ficheros y no tiene ningún
> problema. De hecho, por descarte he dado a un fichero psd concreto todos
> los permisos y pasa exactamente lo mismo.
> 
> http://imgur.com/MmTLKey

¿"Abrir" o "guardar"? 

Porque dices "abrir" pero en la imagen pone "guardar".
 
> Esto no creo que sea problema de permisos, de samba sino más bien de la
> aplicación photoshop, algún fichero temporal que genera o algo así...
> 
> Os ha pasado alguno??
> 
> Con word, excell, powerpoint, txt...etc no tengo ningún problema.
> 
> Gracias de antemano.

Me pasa con ciertos archivos y en un volumen no samba sino nativo de 
Windows (es decir, el cliente usa linux y accede a servidores windows). 
Por ejemplo, los documentos de MS Office, no hay error pero no se abren 
correctamente. Imágenes, texto y PDF se abren sin problemas.

En cambio, la situación que describes no la puedo reproducir (en cliente 
windows y servidor samba) un archivo PSD se abre sin problemas con 
Fireworks, en este caso. Mira, es verdad... prueba a abrirlo desde otra 
aplicación que no sea Adobe Photoshop para descartar o confirmar el 
origen del problema.

Saludos,

-- 
Camaleón

Re: Permisos para crear fichero PID

[Josu Lazkano]

El día 10 de noviembre de 2015, 16:03, Camaleón <noela...@gmail.com> escribió:
> El Mon, 09 Nov 2015 17:26:04 +0100, Josu Lazkano escribió:
>
>> Hola a todos,
>>
>> Estoy configurando el servico de transmission-daemon para poder
>> compartir contenido en internet. Estoy viendo en los logs que el
>> servicio no puede crear el fichero PID en /var/run/
>>
>> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
>> 14:47:28.087 CET] Unable to save pidfile
>> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
>>
>> El usuario con que se ejecuta el servicio es "debian-transmission":
>>
>> # id debian-transmission uid=108(debian-transmission)
>> gid=114(debian-transmission) groups=114(debian-transmission)
>>
>> Originalmente el PID se gaurdaba en
>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>> no se si importa.
>>
>> ¿Como puedo hacer para que se pueda crear ese fichero?
>
> Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo?
>
> Vuelve a dejarlo como estaba y si funciona seguramente sea porque el
> directorio donde se guardaba el PID del servicio tenía los permisos
> adecuados para que el usuario "debian-transmission" tuviera acceso de
> escritura en él.
>
> Por otra parte no dices si usas sysvinit o systemd y eso puede marcar una
> diferencia.
>
> Saludos,
>
> --
> Camaleón
>

Hola de nuevo y gracias por responder,

Creo que utilizo el systemd, tengo el que viene por defecto con Debian Jessie.

Me acabo de dar cuenta que tambien me pasa con otro servicio. Y es a
raiz de alguna actualizacion, no se exactamente cual. Antes no tenia
este problema.

El servicio mythbackend tampoco puedo ejecutarlo:

root@server:~# ls -al /var/run/mythtv/
total 0
drw-r-xr-x  2 mythtv root  40 Nov 24 17:54 .
drwxr-xr-x 25 root   root 880 Nov 24 17:54 ..
root@server:~# /etc/init.d/mythtv-backend start
[] Starting mythtv-backend (via systemctl):
mythtv-backend.serviceJob for mythtv-backend.service failed. See
'systemctl status mythtv-backend.service' and 'journalctl -xn' for
details.
 failed!
root@server:~# chmod 755 /var/run/mythtv/
root@server:~# /etc/init.d/mythtv-backend start
[ ok ] Starting mythtv-backend (via systemctl): mythtv-backend.service.

Lo malo es que si reinicio el servidor se vuelve a poner los valores
de por defecto y tengo que hacer el chmod.

En la lista de deb-multimedia (de donde es el servicio mythbackend) me
dicen que a ellos por defecto les viene asi los permisos:

[stse@osgiliath]: ls -al /var/run/mythtv/
insgesamt 4
drwxr-xr-x  2 mythtv root 60 Nov 24 07:39 .
drwxr-xr-x 44 root   root   1580 Nov 24 14:30 ..
-rw-r–r–  1 mythtv mythtv5 Nov 24 07:39 mythbackend.pid

Cuando a mi me falta la "x" del directorio:

root@server:~# ls -al /var/run/mythtv/
total 0
drw-r-xr-x  2 mythtv root  40 Nov 24 17:54 .
drwxr-xr-x 25 root   root 880 Nov 24 17:54 ..

No se como resolver el problema. Lo unico raro que tengo es que
utilizo el kernel del repositorio jessie-backports, he probado a poner
el de jessie y me pasa lo mismo.

¿Como puedo hacer que los cambios que haga en el /run se mantengan
despues de los reinicios?

Gracias por todo y saludos.

-- 
Josu Lazkano

Re: Permisos para crear fichero PID

[Camaleón]

El Mon, 09 Nov 2015 17:26:04 +0100, Josu Lazkano escribió:

> Hola a todos,
> 
> Estoy configurando el servico de transmission-daemon para poder
> compartir contenido en internet. Estoy viendo en los logs que el
> servicio no puede crear el fichero PID en /var/run/
> 
> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
> 14:47:28.087 CET] Unable to save pidfile
> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
> 
> El usuario con que se ejecuta el servicio es "debian-transmission":
> 
> # id debian-transmission uid=108(debian-transmission)
> gid=114(debian-transmission) groups=114(debian-transmission)
> 
> Originalmente el PID se gaurdaba en
> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
> no se si importa.
> 
> ¿Como puedo hacer para que se pueda crear ese fichero?

Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo? 

Vuelve a dejarlo como estaba y si funciona seguramente sea porque el 
directorio donde se guardaba el PID del servicio tenía los permisos 
adecuados para que el usuario "debian-transmission" tuviera acceso de 
escritura en él.

Por otra parte no dices si usas sysvinit o systemd y eso puede marcar una 
diferencia.

Saludos,

-- 
Camaleón

Re: Permisos para crear fichero PID

[Josu Lazkano]

El día 9 de noviembre de 2015, 17:47, fernando sainz
<fernandojose.sa...@gmail.com> escribió:
> El día 9 de noviembre de 2015, 17:26, Josu Lazkano
> <josu.lazk...@gmail.com> escribió:
>> Hola a todos,
>>
>> Estoy configurando el servico de transmission-daemon para poder
>> compartir contenido en internet. Estoy viendo en los logs que el
>> servicio no puede crear el fichero PID en /var/run/
>>
>> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
>> 14:47:28.087 CET] Unable to save pidfile
>> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
>>
>> El usuario con que se ejecuta el servicio es "debian-transmission":
>>
>> # id debian-transmission
>> uid=108(debian-transmission) gid=114(debian-transmission)
>> groups=114(debian-transmission)
>>
>> Originalmente el PID se gaurdaba en
>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>> no se si importa.
>>
>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>
>> Un saludo.
>>
>> --
>> Josu Lazkano
>>
>  Ese directorio es de root y tiene los permisos:
>
> drwxr-xr-x 29 root root 1240 nov  9 16:12 /run
>
> Por lo que otro usuario no puede "CREAR" ficheros pero si podría
> escribir si el fichero existiera y su propietario fuera ese usuario.
> (man chown)
>
> Si te fijas en los que tienes verás que hay ficheros y directorios con
> propietario distinto de root
> Si el directorio te pertenece podrás crear ficheros en él.
>
> S2.
>

Gracias por contestar Fernando,

Me he fijado que existen archivos y directorios con usuarios y grupos
diferentes a root,

Pero por lo que veo el direcotrio /run esta montado sobre un fs volatil:

# df -h | grep run
tmpfs   396M  5.5M  391M   2% /run
tmpfs   5.0M 0  5.0M   0% /run/lock

Puede que sea por eso que cada vez que arranque pierda toda la
informacion y despues no pueda crear dicho fichero.

Pero por esa razon, los demos directorios tampoco existirian:

# ls -lh /run/ | grep -v root
total 60K
drwxr-x---  2 Debian-exim Debian-exim   60 Nov  9 22:28 exim4
-rw-r--r--  1 statd   nogroup4 Nov  9 22:28 rpc.statd.pid

¿Se os ocurre algo?

Gracias por todo y un saludo.

-- 
Josu Lazkano

Re: Permisos para crear fichero PID

[fernando sainz]

El día 9 de noviembre de 2015, 22:34, Josu Lazkano
<josu.lazk...@gmail.com> escribió:
> El día 9 de noviembre de 2015, 17:47, fernando sainz
> <fernandojose.sa...@gmail.com> escribió:
>> El día 9 de noviembre de 2015, 17:26, Josu Lazkano
>> <josu.lazk...@gmail.com> escribió:
>>> Hola a todos,
>>>
>>> Estoy configurando el servico de transmission-daemon para poder
>>> compartir contenido en internet. Estoy viendo en los logs que el
>>> servicio no puede crear el fichero PID en /var/run/
>>>
>>> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
>>> 14:47:28.087 CET] Unable to save pidfile
>>> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
>>>
>>> El usuario con que se ejecuta el servicio es "debian-transmission":
>>>
>>> # id debian-transmission
>>> uid=108(debian-transmission) gid=114(debian-transmission)
>>> groups=114(debian-transmission)
>>>
>>> Originalmente el PID se gaurdaba en
>>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>>> no se si importa.
>>>
>>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>>
>>> Un saludo.
>>>
>>> --
>>> Josu Lazkano
>>>
>>  Ese directorio es de root y tiene los permisos:
>>
>> drwxr-xr-x 29 root root 1240 nov  9 16:12 /run
>>
>> Por lo que otro usuario no puede "CREAR" ficheros pero si podría
>> escribir si el fichero existiera y su propietario fuera ese usuario.
>> (man chown)
>>
>> Si te fijas en los que tienes verás que hay ficheros y directorios con
>> propietario distinto de root
>> Si el directorio te pertenece podrás crear ficheros en él.
>>
>> S2.
>>
>
> Gracias por contestar Fernando,
>
> Me he fijado que existen archivos y directorios con usuarios y grupos
> diferentes a root,
>
> Pero por lo que veo el direcotrio /run esta montado sobre un fs volatil:
>
> # df -h | grep run
> tmpfs   396M  5.5M  391M   2% /run
> tmpfs   5.0M 0  5.0M   0% /run/lock
>
> Puede que sea por eso que cada vez que arranque pierda toda la
> informacion y despues no pueda crear dicho fichero.
>
> Pero por esa razon, los demos directorios tampoco existirian:
>
> # ls -lh /run/ | grep -v root
> total 60K
> drwxr-x---  2 Debian-exim Debian-exim   60 Nov  9 22:28 exim4
> -rw-r--r--  1 statd   nogroup4 Nov  9 22:28 rpc.statd.pid
>
> ¿Se os ocurre algo?
>
> Gracias por todo y un saludo.
>
> --
> Josu Lazkano
>

Vale, no tengo el demonio ese instalado, pero imagino que se arrancará
como los demás desde un script en /etc/init.d
He visto otros demonios y aquí crean el directorio que usan y le
cambian de propietario.
(No se si en Jessie esto va igual, pero ahora no estoy en ella.)

Ahí probablemente vendrá donde quiere escribir el .pid

Ten en cuenta que la mayor parte de los demonios se inician por root,
pero luego cambian su id a otro usuario para evitar problemas de
seguridad.

S2.

Re: Permisos para crear fichero PID

[fernando sainz]

El día 9 de noviembre de 2015, 17:26, Josu Lazkano
<josu.lazk...@gmail.com> escribió:
> Hola a todos,
>
> Estoy configurando el servico de transmission-daemon para poder
> compartir contenido en internet. Estoy viendo en los logs que el
> servicio no puede crear el fichero PID en /var/run/
>
> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
> 14:47:28.087 CET] Unable to save pidfile
> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
>
> El usuario con que se ejecuta el servicio es "debian-transmission":
>
> # id debian-transmission
> uid=108(debian-transmission) gid=114(debian-transmission)
> groups=114(debian-transmission)
>
> Originalmente el PID se gaurdaba en
> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
> no se si importa.
>
> ¿Como puedo hacer para que se pueda crear ese fichero?
>
> Un saludo.
>
> --
> Josu Lazkano
>
 Ese directorio es de root y tiene los permisos:

drwxr-xr-x 29 root root 1240 nov  9 16:12 /run

Por lo que otro usuario no puede "CREAR" ficheros pero si podría
escribir si el fichero existiera y su propietario fuera ese usuario.
(man chown)

Si te fijas en los que tienes verás que hay ficheros y directorios con
propietario distinto de root
Si el directorio te pertenece podrás crear ficheros en él.

S2.

Permisos para crear fichero PID

[Josu Lazkano]

Hola a todos,

Estoy configurando el servico de transmission-daemon para poder
compartir contenido en internet. Estoy viendo en los logs que el
servicio no puede crear el fichero PID en /var/run/

Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
14:47:28.087 CET] Unable to save pidfile
"/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)

El usuario con que se ejecuta el servicio es "debian-transmission":

# id debian-transmission
uid=108(debian-transmission) gid=114(debian-transmission)
groups=114(debian-transmission)

Originalmente el PID se gaurdaba en
"/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
no se si importa.

¿Como puedo hacer para que se pueda crear ese fichero?

Un saludo.

-- 
Josu Lazkano

Re: Permisos para crear fichero PID

[Josu Lazkano]

El día 9 de noviembre de 2015, 23:14, fernando sainz
<fernandojose.sa...@gmail.com> escribió:
> El día 9 de noviembre de 2015, 22:34, Josu Lazkano
> <josu.lazk...@gmail.com> escribió:
>> El día 9 de noviembre de 2015, 17:47, fernando sainz
>> <fernandojose.sa...@gmail.com> escribió:
>>> El día 9 de noviembre de 2015, 17:26, Josu Lazkano
>>> <josu.lazk...@gmail.com> escribió:
>>>> Hola a todos,
>>>>
>>>> Estoy configurando el servico de transmission-daemon para poder
>>>> compartir contenido en internet. Estoy viendo en los logs que el
>>>> servicio no puede crear el fichero PID en /var/run/
>>>>
>>>> Nov  9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09
>>>> 14:47:28.087 CET] Unable to save pidfile
>>>> "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573)
>>>>
>>>> El usuario con que se ejecuta el servicio es "debian-transmission":
>>>>
>>>> # id debian-transmission
>>>> uid=108(debian-transmission) gid=114(debian-transmission)
>>>> groups=114(debian-transmission)
>>>>
>>>> Originalmente el PID se gaurdaba en
>>>> "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta,
>>>> no se si importa.
>>>>
>>>> ¿Como puedo hacer para que se pueda crear ese fichero?
>>>>
>>>> Un saludo.
>>>>
>>>> --
>>>> Josu Lazkano
>>>>
>>>  Ese directorio es de root y tiene los permisos:
>>>
>>> drwxr-xr-x 29 root root 1240 nov  9 16:12 /run
>>>
>>> Por lo que otro usuario no puede "CREAR" ficheros pero si podría
>>> escribir si el fichero existiera y su propietario fuera ese usuario.
>>> (man chown)
>>>
>>> Si te fijas en los que tienes verás que hay ficheros y directorios con
>>> propietario distinto de root
>>> Si el directorio te pertenece podrás crear ficheros en él.
>>>
>>> S2.
>>>
>>
>> Gracias por contestar Fernando,
>>
>> Me he fijado que existen archivos y directorios con usuarios y grupos
>> diferentes a root,
>>
>> Pero por lo que veo el direcotrio /run esta montado sobre un fs volatil:
>>
>> # df -h | grep run
>> tmpfs   396M  5.5M  391M   2% /run
>> tmpfs   5.0M 0  5.0M   0% /run/lock
>>
>> Puede que sea por eso que cada vez que arranque pierda toda la
>> informacion y despues no pueda crear dicho fichero.
>>
>> Pero por esa razon, los demos directorios tampoco existirian:
>>
>> # ls -lh /run/ | grep -v root
>> total 60K
>> drwxr-x---  2 Debian-exim Debian-exim   60 Nov  9 22:28 exim4
>> -rw-r--r--  1 statd   nogroup4 Nov  9 22:28 rpc.statd.pid
>>
>> ¿Se os ocurre algo?
>>
>> Gracias por todo y un saludo.
>>
>> --
>> Josu Lazkano
>>
>
> Vale, no tengo el demonio ese instalado, pero imagino que se arrancará
> como los demás desde un script en /etc/init.d
> He visto otros demonios y aquí crean el directorio que usan y le
> cambian de propietario.
> (No se si en Jessie esto va igual, pero ahora no estoy en ella.)
>
> Ahí probablemente vendrá donde quiere escribir el .pid
>
> Ten en cuenta que la mayor parte de los demonios se inician por root,
> pero luego cambian su id a otro usuario para evitar problemas de
> seguridad.
>
> S2.
>

Gracias de nuevo,

Tienes razon, aqui esta el script de init: http://paste.debian.net/330503/

Tambien esta el fichero /etc/default/transmission-daemon:
http://paste.debian.net/330504/

De momento he configurado el /etc/rc.local asi:

mkdir /var/run/transmission
chown debian-transmission:debian-transmission /var/run/transmission/

Ya se que no es la mejor forma pero para pasar del paso me funciona.

Muchas gracias por vuestra ayuda.

Saludos.

-- 
Josu Lazkano

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

[Ramses]

El 11 de octubre de 2015 08:10:00 CEST, Frederit Mogollon 
<frederitmogol...@gmail.com> 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@Te

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

[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

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

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

[Frederit Mogollon]

2015-10-11 4:40 GMT-04:30, Manolo Díaz <diaz.man...@gmail.com>:
> 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 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

[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 [SOLUCIONADO]

[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

[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 <noela...@gmail.com>:
> 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

[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

[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

[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

[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

[Frederit Mogollon]

2015-10-10 13:09 GMT-04:30, Santiago Vila <sanv...@unex.es>:
> 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

[Frederit Mogollon]

2015-10-10 10:41 GMT-04:30, Camaleón <noela...@gmail.com>:
> 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

[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

[Frederit Mogollon]

2015-10-10 10:54 GMT-04:30, Manolo Díaz <diaz.man...@gmail.com>:
> 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

[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

[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

[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

[Frederit Mogollon]

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 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 90 sin
actualizar.
---


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

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


6. Se reinició el sistema desde el hardware, y se ingresó al sistema
mediante el kernel linux-image-3.2.0-4-686-pae.


7. Nuevamente ejecutó la siguiente secuencia de órdenes para
cuantificar la cantidad de paquetes instalados desde backports:
-
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

0
-


8. Para verificar que todo lo necesario fuese actualizado, se ejecutó la orden:
-
root@Tesistas:/home/tesistas# aptitude upgrade

No se instalará, actualizará o eliminará ningún paquete.
0 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 70 sin
actualizar.
---


9. Se eliminó la configuración anteriormente añadida en el fichero
/etc/apt/preferences.


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:


root@Tesistas:/home/tesistas# aptitude -t wheezy-backports install
p11-kit-modules:i386 pepperflashplugin-nonfree:i386

Se instalarán libtasn1-6:i386 y p11-kit-modules:i386


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.


11. 

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

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

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

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

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

[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

Re: usuarios y permisos

[Camaleón]

El Wed, 03 Dec 2014 23:59:45 -0300, unciegobailando escribió:

 El 03/12/14 a las 13:40, Camaleón escibió:
 El Wed, 03 Dec 2014 13:27:10 -0300, Gonzalo Rivero escribió:

 El mié, 03-12-2014 a las 11:52 -0430, Edward Villarroel (EDD)
 escribió:
 buenas tardes puedo darle a usuarios normales permisos para ejecutar
 una cantidad de comandos especificos


 osea seria como tener un suarios edward que nada mas pueda crear
 usuarios nuevos y modificar sus password


 pero mas nada que nos sea root?

 man sudo

 sm01@stt008:~$ man sudo
 No manual entry for sudo

 :-P
 
 Para ver online:
 
 http://manpages.debian.org

(...)

Parece que se te ha pasado el :-P.

No tengo nada en contra de las páginas del manual sólo que cuando se no 
se tiene una aplicación instalada no están disponibles, eso era lo que 
quería decir (recuerda que sudo no siempre se instala de serie en Debian 
dependiendo del tipo de instalación que hagas, por eso yo no lo tengo 
instalado).

Además, raramente las páginas del manual te explican cómo configurar una 
aplicación, simplemente enumeran los parámetros disponibles y qué hacen 
cada uno de ellos. Si tienes suerte, puedes tener ejemplos de uso pero 
poco más.

La página de la wiki de Debian está muy bien porque te explica cómo 
configurar sudo para que usuarios determinados tengan acceso a ciertos 
comandos.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.12.04.14.45...@gmail.com

usuarios y permisos

[Edward Villarroel (EDD)]

buenas tardes puedo darle a usuarios normales permisos para ejecutar
una cantidad de comandos especificos


osea seria como tener un suarios edward que nada mas pueda crear
usuarios nuevos y modificar sus password


pero mas nada que nos sea root?



Edward Villarroel:  @Agentedd


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADfsJo0M=aarjs5a7hnngxdsys6qt6gmagvvlhfq_sjsw-b...@mail.gmail.com

Re: usuarios y permisos

[Gonzalo Rivero]

El mié, 03-12-2014 a las 11:52 -0430, Edward Villarroel (EDD) escribió: 
 buenas tardes puedo darle a usuarios normales permisos para ejecutar
 una cantidad de comandos especificos
 
 
 osea seria como tener un suarios edward que nada mas pueda crear
 usuarios nuevos y modificar sus password
 
 
 pero mas nada que nos sea root?
 
 
 
 Edward Villarroel:  @Agentedd
 
 
man sudo

-- 
(-.(-.(-.(-.(-.(-.-).-).-).-).-).-)



-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417624030.1165.11.ca...@gmail.com

Re: usuarios y permisos

[Camaleón]

El Wed, 03 Dec 2014 13:27:10 -0300, Gonzalo Rivero escribió:

 El mié, 03-12-2014 a las 11:52 -0430, Edward Villarroel (EDD) escribió: 
 buenas tardes puedo darle a usuarios normales permisos para ejecutar
 una cantidad de comandos especificos
 
 
 osea seria como tener un suarios edward que nada mas pueda crear
 usuarios nuevos y modificar sus password
 
 
 pero mas nada que nos sea root?
 
 man sudo

sm01@stt008:~$ man sudo
No manual entry for sudo

:-P

https://wiki.debian.org/sudo
http://linuxgnublog.org/configurar-sudo-en-debian

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.12.03.16.40...@gmail.com