Hola a tod@s: El día 17 de octubre de 2008 17:57, Shinji Ikari escribió:

?? cual es la finalidad de eso? tiene usuarios los cuales pertenecen al mismo grupo, no? y quiere que uno de los archivos pase a ser propiedad exclusiva de uno de los usuarios a fin de que no lo puedan leer-escribir los otros?

Es correcto ... tal cual lo has dicho.

Como dijo Jack, vayamos por partes. Hay que ordenar bien la cuestión para que no sea necesario "enredar" el sistema. =/

Veamos si lo logro: necesito bloquear un archivo para que no pueda ser modificado de manera concurrente, así que la manera más sencilla que encontré fué crear un par de rutinas que lo que hacen es operar partiendo del propietario del archivo en cuestión, así: Bloqueo: Si el propietario del archivo es usuariox (usuario genérico), bloquee el archivo para usuario1 (O usuario2, usuario3, etc ... según el usuario que active la rutina). Si el propietario del archivo es usuario1 (O usuario2, usuario3, etc), y otro usuario diferente (al propietario del archivo y al usuario genérico) activa la rutina de bloqueo, la rutina muestra un mensaje de error. Desbloqueo: Si el propietario del archivo es usuario1, y el propietario del archivo activa ésta rutina, cambia el propietario del archivo al usuario genérico (usuariox). Si el propietario del archivo es usuario1 (O usuario2, usuario3, etc ... según el usuario que active la rutina), y otro usuario diferente activa la rutina de desbloqueo, la rutina muestra un mensaje de error. El problema que tengo radica en que los usuarios se conectan con un usuario genérico (usuariox), pero requiero que hagan el cambio de propietario (chown) a un usuario único asignado a cada cliente de ese servidor común (usuario1, usuario2, usuario3, etc). Para hacer el cambio, requiero que cada usuario se identifique con su clave del sistema (para eso requiero el uso de su/sudo) ... pero hasta ahora no lo he logrado ... :'-((( Espero haberme hecho entender ... quedo atento a sus respuestas, comentarios, indicaciones. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-17 a las 18:35 -0500, Shinji Ikari escribió:

Yo como usuario doméstico no entiendo lo que has escrito -_-

La idea es muy simple, y se la di yo en otro correo hace una semana o dos, lo puedes buscar facilmente. Antes de editar un archivo determinado, se cambia el propietario del archivo al del usuario, con lo que sólo ese usuario puede cambiarlo. Al terminar de editar, se vuelve a poner como propietario a otro. No es una cosa que se pueda conseguir con grupos. Tampoco estoy seguro que se pueda conseguir, ya lo dije en su dia. Y ahora no puedo pensarlo, estoy espeso. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj5PQkACgkQtTMYHG2NR9XO2QCdFlCl0xTtiw+GQENYmI92JHX0 yGAAoJCPp2e1Lr5xWKKYhreQDmzTn9oJ =0OIu -----END PGP SIGNATURE-----

2008/10/20 RŌNIN :

Hola a tod@s

El día 17 de octubre de 2008 20:34, Carlos E. R. escribió:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2008-10-17 a las 18:35 -0500, Shinji Ikari escribió:

La idea es muy simple, y se la di yo en otro correo hace una semana o dos, lo puedes buscar facilmente.

Antes de editar un archivo determinado, se cambia el propietario del archivo al del usuario, con lo que sólo ese usuario puede cambiarlo. Al terminar de editar, se vuelve a poner como propietario a otro.

No es una cosa que se pueda conseguir con grupos. Tampoco estoy seguro que se pueda conseguir, ya lo dije en su dia. Y ahora no puedo pensarlo, estoy espeso.

Es correcto ... tal cual fué tu idea, tal cual hice las tan mentadas rutinas ;-)

Las rutinas me han funcionado bien, sólo que me siguen pidiendo la contraseña del administrador para ejecutar el cambio de propietario, y lo que quiero es que (veamos si logro aclararte o espesarte más) a pesar que ingreso como usuario genérico al sistema ejecute la rutina como el usuario que soy (llámese winusuario1, winusuario2, etc.) y que dicho usuario (llámese winusuario1, winusuario2, etc.) pueda ejecutar el comando chown (que actualmente sólo lo puede ejecutar el/como administrador), pidiendo la contraseña del usuario en cuestión (llámese winusuario1, winusuario2, etc.), no la del administrador.

Gracias por tu tiempo e interés.

Cordialmente,

Cuervo Linuxero

Saludos, veo un problema a futuro y es que el programa depende de que el usuario propietario del archivo devuelva la propiedad al usuario generico para que esté disponible para los otros usuarios. No es por dar la lata pero se veia venir. =( Que tal si se añade un reloj, que define el usuario que va utilizar el archivo, y además se reporte quien está utilizando el archivo. Aqui lo importante es que fluya información y que no se pierdan los archivos. (The spice must flow - The information must flow XD) -_- Pero igual, creo yo que la idea de "ordenar" el trabajo de los esclavos digitadores debería tener prioridad. Suerte. =) -- Carlos A.

Hola a tod@s: El día 20 de octubre de 2008 14:47, Carlos E. R. escribió:

Vale, te pide la del administrador. Si tienes estas dos lineas:

Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!

las quitas, es decir, las comentas. A partir de ese momento, te pedirá la contraseña del usuario con el que has entrado: no es posible, que yo sepa, hacer que pida la contraseña de un usuario arbitrario.

Y el meollo del asunto: 1. No tengo las líneas que me indican en mi archivo /etc/sudoers ... ?:S 2. ¿Esta línea en mi rutina está bien o está errada (Considerando lo que quiero hacer)?: usuariox@testserver:~$su usuario1 chown usuario1 prueba.txt Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El día 20 de octubre de 2008 18:09, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Mal, claro: no es "su" sino "sudo". Y no puedes especificar usuario.

Para hacerlo con "su" necesitas la contraseña del usuario1; y además la sintaxis es incorrecta, porque el comando "chown" tendría que estar detrás de un "-c".

¿A que no te has leído el manual de su ni de sudo? :-P

Leí tantos que terminé como lombriz en spaguetti ... @:S Veamos ... así las cosas, el comando correcto sería: 1. usuariox@testserver:~$su usuario1 -c chown usuario1 prueba.txt 2. usuariox@testserver:~$sudo usuario1 ; -c chown usuario1 prueba.txt Me enrredé otra vez ... cataplum !!! Sería agregar en la rutina "algo" que pida primero la identidad del usuario y su clave (¿como contrasto esto con la del sistema?) ... y luego ejecute el sudo chown ... ¿ o algo así ?. A éste punto voy más perdido que un viajero en Siria o Egipto (donde prohibieron el uso de GPS) ... SOS !!!!! Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El día 20 de octubre de 2008 18:46, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

Y le pedirá la contraseña de "usuario1", con lo cual el comando "chown...." fallará, porque si el fichero no es ya de "usuario1" no tendrá permisos para cambiarlos. Se ejecuta con los privilegios de "usuario1". Sólo el propietario puede cambiar permisos.

Eso no es sudo, el fichero /etc/sudoers se ignora.

Este es justamente el comportamiento que requiero: que pida la contraseña del usuario1 (el que se especifica) y no la del usuario que tiene activa la sesión en el sistema (usuariox). Hice el ensayo (usuariox@testserver:~$ su usuario1 -c chown usuario1 prueba.txt) y la respuesta fué: Contraseña: chown: falta un operando Pruebe `chown --help' para más información. Lo que me alegra es haber descubierto que si ingreso la clave del usuario activo en el sistema (usuariox), me presenta fallo de autenticación, lo que quiere decir que sólo me acepta la del usuario1 (Justo lo que requiero que haga). Surge mi pregunta: ¿qué está mal con el chown? ... :( Si lo hago con sudo (usuariox@testserver:~$ sudo usuario1 -c chown usuario1 prueba.txt), me pide la clave del usuario que está activo en el sistema (usuariox); por lo cual deduzco que para lo que requiero, mejor paso del sudo.

Y es el /etc/sudoers quien determina que contraseña le pide y a qué usuario le va a convertir. Y como deseas convertir un fichero que no es suyo, tienes dos alternativas: convertirlo en genérico o en root. Tendrías que poner:

Pero es la rutina lo que establece el propietario del archivo, así que lo único que debo establecer en el sudo, así que me surge otra pregunta: ¿cómo establecer quien(es) pueden hacer uso del chown?

Primero olvidate del script y consigue que funcione en consola. Recuerda que si fallas dos o tres veces con el sudo se autobloquea y no te permite probar más: y no te lo dice, te deja probar hasta que te aburras, pero no te hace caso, aunque mandará un correo al root en secreto.

Creo que empiezo a aburrirme, sin necesidad que el sudo se autobloquee ... :-((( Ya estoy embotado con éste proyecto y de buena gana lo tiraría ... pero con esas amenazas de fuerte desempleo a nivel mundial, creo que no me queda de otra que seguir acudiendo a su invaluable ayuda ... hasta que logre entregarlo ... sniff, sniff. Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El día 21 de octubre de 2008 9:37, Camaleón escribió:

Usa comillas :-?:

su usuario1 -c "chown usuario1 prueba.txt"

Eres GRANDIOSA !!!! @>--}--- Otro que muerde el polvo !!!! >:-) usuariox@testserver:~$ su usuario1 -c "chown usuario1 prueba.txt" Password: Pero: chown: changing ownership of `prueba.txt': Operation not permitted (GGGRRRRR!!!!!!!!! ... ya lo tenía ... sniff, sniff, sniff) Aquí sospecho que hay algo que ajustar en mi /etc/sudoers: # /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaults env_reset # Uncomment to allow members of group sudo to not need a password # %sudo ALL=NOPASSWD: ALL # Host alias specification # User alias specification User_Alias OPERADORES=usuario1,usuario2,usuario3 # Cmnd alias specification Cmnd_Alias CAMBIAR=/usr/bin/chown # User privilege specification root ALL=(ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL OPERADORES ALL=(root) CAMBIAR Pero sospecha sin conocimiento, no creo que me ayude a resolver nada ... :-( Quedo atento a sus comentarios / opiniones / sugerencias ... Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El día 21 de octubre de 2008 10:05, Camaleón escribió:

El 21/10/08, RŌNIN escribió:

...

chown: changing ownership of `prueba.txt': Operation not permitted (GGGRRRRR!!!!!!!!! ... ya lo tenía ... sniff, sniff, sniff)

Revisa los permisos del archivo (usuario, grupo...) :-?

-rw-rw-rw- 1 usuariox usuariox 0 2008-10-16 12:33 prueba.txt ... |:-S

Pero "su" no usa "sudo"... no veo relación :-?.

Ejem ... tu sabes: cuando se habla desde la ignorancia, todo es posible ... O:-) Como dijo mi sabia abuela: "Expertos tiene la Lista que saben responder" ... así que sigo aquí molestándoles con mis preguntas. ;-) Quedo a la espera de sus comentarios/sugerencias/indicaciones. Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html =��u��y��jV���+��"�f�u맙��j7������zϮ�˛���m�)z{.��+���j��zw�zZ޲�yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 09:55 -0500, RŌNIN escribió:

usuariox@testserver:~$ su usuario1 -c "chown usuario1 prueba.txt" Password:

Pero:

chown: changing ownership of `prueba.txt': Operation not permitted (GGGRRRRR!!!!!!!!! ... ya lo tenía ... sniff, sniff, sniff)

Claro. Sólo root puede cambiar propietarios arbitrariamente. Observa: cer@nimrodel:~> l pruebas.txt - -rw-r--r-- 1 cer users 0 2008-10-21 20:08 pruebas.txt cer@nimrodel:~> chown cer2 pruebas.txt chown: changing ownership of `pruebas.txt': Operation not permitted cer@nimrodel:~> su cer2 Password: cer2@nimrodel:/home/cer> chown cer2 pruebas.txt chown: changing ownership of `pruebas.txt': Operation not permitted cer2@nimrodel:/home/cer>

Aquí sospecho que hay algo que ajustar en mi /etc/sudoers:

Para nada, ya te lo dije: el "su" no tiene nada que ver con "sudo".

Quedo atento a sus comentarios / opiniones / sugerencias ...

Estudiate el manual, te van las habichuelas en ello >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+G8cACgkQtTMYHG2NR9VyPwCeLiOwJcRDs/WKuJ/RDF3ZeuHa SFgAniacNhW6jeHnSQ+r0ZpR8Z6WtVkL =CYBr -----END PGP SIGNATURE-----

El 21/10/08, RŌNIN escribió:

1. No pude ver el último mensaje de Camaleón como respuesta a mi caso , ¿alguien me lo reenvía, por favor?.

Lo siento... la verdad es que sé que es una lata esto de los mensajes en blanco para los que usamos el webmail de gmail. Deberíamos usar otro cliente... http://lists.opensuse.org/opensuse-es/2008-10/msg00896.html Pero parece que el uso de chown sólo se permite al root. Por seguridad, supongo :-? (...) Aquí explican algo... *** http://www.unix.com.ua/orelly/networking/puis/ch05_07.htm (...) In earlier versions of UNIX, all users could run the chown command to change the ownership of a file that they owned to that of any other user on the system. This let them "give away" a file. The feature made sharing files back and forth possible, and allowed a user to turn over project directories to someone else. Allowing users to give away files can be a security problem because it makes a miscreant's job of hiding his tracks much easier. If someone has acquired stolen information or is running programs that are trying to break computer security, that person can simply change the ownership of the files to that of another user. If he sets the permissions correctly, he can still read the results. Permitting file give-aways also makes file quotas useless: a user who runs out of quota simply changes the ownership of his larger files to another user. Worse, perhaps, he can create a huge file and change its ownership to someone else, exceeding the user's quota instantly. If the file is in a directory to which the victim does not have access, he or she is stuck. *** Interesante :-) Saludos, -- Camaleón

El día 21 de octubre de 2008 18:17, RŌNIN escribió:

Hola a tod@s:

Así parece ... lo cual me lleva a los orígenes de éste rollo:

1. ¿cómo hacer que el usuario1 ejecute el comando chown como si fuera el administrador?.

2. ¿cómo hacer que al ejecutar el comando chown, no pida la contraseña del administrador, sino la del usuario1?.

De veras que ya tengo agotamiento mental por cuenta de ésto ... no entiendo nada :-(

Quedo atento a sus comentarios/indicaciones/sugerencias.

Cordialmente,

Cuervo Linuxero

Er mi respuesta original: * Comenta las siguientes lineas: #Defaults targetpw # ask for the password of the target user i.e. root #ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! * Define el alias con usuario1 como miembro User_Alias OPERADORES = usuario1 * Cambia la regla a "OPERADORES ALL=(root) CAMBIAR" * Como usuario1: "sudo chown usuario /path/al/archivo" CI.- =��u��y��jV���+��"�f�u맙��j7������zϮ�˛���m�)z{.��+���j��zw�zZ޲�yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2008-10-21 a las 16:51 -0500, RŌNIN escribió: ...

Par preguntas aquí:

1. ¿Esto implica que debo ingresar al servidor remoto como usuario1?

Sip.

2. ¿Cómo puedo hacerlo habiendo ingresado como usuariox?

No puedes. Al menos que yo sepa. A no ser que les hagas hacer: su usuario1 -c sudo chown usuario1 fichero ...con lo que pedirá DOS veces la clave de usuario1. Claro, que podrías pensar en pedir tu la clave en el script, guardarla, y dársela a los comandos en cuestión: pero eso es otra "lata de gusanos", en la expresión inglesa, porque te encontrarías que no puedes pasarle la clave a su ni sudo de manera fácil. Yo no sé hacerlo, y sé que no sé hacerlo porque lo he intentado. La otra posibilidad sería usar: usuario1 ALL=(root) NOPASSWD: /bin/chown usuario1 /path/* pero eso tiene problemas de seguridad obvios: el usuario 2 (y el 3, y el 4...) podría entrar por consola y cambiar el propietario de cualquier archivo en el path (¿a cualquier propietario?) del grupo, porque no le va a pedir la contraseña. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+UqkACgkQtTMYHG2NR9WVWwCbBKsDkSX/hWpRlRVd7DJvLCSP /jkAniN5JuQLRHI0r/mXXv0ypTn8xJfL =e4oI -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 20:10 -0200, Gabriel escribió:

...

La otra posibilidad sería usar:

usuario1 ALL=(root) NOPASSWD: /bin/chown usuario1 /path/*

pero eso tiene problemas de seguridad obvios: el usuario 2 (y el 3, y el 4...) podría entrar por consola y cambiar el propietario de cualquier archivo en el path (¿a cualquier propietario?) del grupo, porque no le va a pedir la contraseña.

Exacto, cada usuario debería loguearse con su propio usuario, no tienen porque conocer la contraseña del usuariox el cual es el único que debería poder ejecutar los comandos con sudo.

Puede que sea un usuario común usado por samba. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+WpUACgkQtTMYHG2NR9UHhACfdP/VQHr4xOlehsFhE1W16qBt ehkAniWN70xCi0zjx6ljh9OXgCtD53Dy =/nTX -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 17:46 -0500, RŌNIN escribió:

Hola a tod@s:

El día 21 de octubre de 2008 17:07, Carlos E. R. escribió:

...

...

Par preguntas aquí:

1. ¿Esto implica que debo ingresar al servidor remoto como usuario1?

Sip.

Va a ser que no: el ingreso está restringido sólo para el usuariox. :-S

La luz del tunel disminuye :-P Vamos a ver, ¿teneis o no teneis programadores en la empresa? Pues que programen una herramienta que haga lo que buscas. Si la herramienta corre como root, y le llegan las peticiones desde los clientes (es decir, una herramienta partida cliente/servidor) pues podreis hacer los cambios de permisos que os de la gana. Y que ellos, que son programadores, se devanen los sesos programando esa herramienta, no tu. Podrías probar si un script ejecutándose con suid sirva, pero me parece recordar que un script no puede ser suid root. Tiene que ser un binario, para no ser pervertido por los usuarios. Y si no, pues hazte programador >:-)

...

...

2. ¿Cómo puedo hacerlo habiendo ingresado como usuariox?

No puedes. Al menos que yo sepa. A no ser que les hagas hacer:

su usuario1 -c sudo chown usuario1 fichero

Esta solución me ha caído como anillo al dedo ... excepto por la doble petición de clave, pero de momento, me parece la ganadora.

No cantes victoria tan rápido...

...

La otra posibilidad sería usar:

usuario1 ALL=(root) NOPASSWD: /bin/chown usuario1 /path/*

pero eso tiene problemas de seguridad obvios: el usuario 2 (y el 3, y el 4...) podría entrar por consola y cambiar el propietario de cualquier archivo en el path (¿a cualquier propietario?) del grupo, porque no le va a pedir la contraseña.

Es un riesgo MUY alto a mi modo de ver ... y si lo dejara así:

usuario1 ALL=(root) /bin/chown usuario1 /path/*

¿Funcionaría como requiero (solicitando la clave al usuario que desea realizar los cambios), sin más? ...

Le pedirá la clave al usuario bajo el que se ejecuta el comando, aquél con el que haya hecho login.

me gustaría conocer la opinión teórica ya que hace algunos días cambié algo en /etc/sudoers y ya luego no me dejó usar el sudo como administrador ... y recomponer el daño me fué tedioso.

Es que esa forma de usar el sudo como administrador es incorrecta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+YSQACgkQtTMYHG2NR9VkEgCdFD5B5oJKbiaRQwIInZ1DACXs yVUAn0cLLQM0HxmNMzLL/iGMyaUk4mCi =I4Y4 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 18:22 -0500, RŌNIN escribió:

Hola a tod@s:

El día 21 de octubre de 2008 18:09, Carlos E. R. escribió:

...

Vamos a ver, ¿teneis o no teneis programadores en la empresa? Pues que programen una herramienta que haga lo que buscas. Si la herramienta corre como root, y le llegan las peticiones desde los clientes (es decir, una herramienta partida cliente/servidor) pues podreis hacer los cambios de permisos que os de la gana. Y que ellos, que son programadores, se devanen los sesos programando esa herramienta, no tu.

Otra que hace que la luz se pierda: aquí no saben mucho de GNU/Linux como para administrarlo u operarlo ... imagina para pedirles una aplicación ... :-(

Vaya.

...

Podrías probar si un script ejecutándose con suid sirva, pero me parece recordar que un script no puede ser suid root. Tiene que ser un binario, para no ser pervertido por los usuarios.

Y si no, pues hazte programador >:-)

Sé algo de C, C++ y Java ... no me considero programador como tal, solo que he tenido que aprender algunas cosas a fuerza, para resolver algunos retos que me han presentado. ¿Crees que un nivel básico pueda servir para lograr lo que quiero?

No lo se. Tampoco tengo apenas experiencia programando para linux, así que no puedo estimarlo. Y desde luego tengo muy poca idea de las consideraciones de seguridad al programar, que es lo importante aquí. Gabriel te podrá decir algo más. Pero con lo mal que te llevas con los manuales, mal te veo :-p En la versión "sencilla" tendrías que hacer lo del script, pero dentro de un programa binario, que además hiciese las operaciones de cambio de propietario de los archivos (lo del chown, sin usar chown, o llamando a chown), para lo cual tiene que ejecutar como root (suid). Al ser root, no necesita pedir permiso a nadie. De alguna forma, pedir contraseña a los usuarios. O contratais a alguien para que os lo haga >:-)

...

No cantes victoria tan rápido...

¿Crees que algo pueda salir mal? :-O

No especificamente... pero dado que lo que buscas es algo extraño, pues no es sencillo.

...

Le pedirá la clave al usuario bajo el que se ejecuta el comando, aquél con el que haya hecho login.

En plata blanca: ésta tampoco sirve ... :-(

...

Es que esa forma de usar el sudo como administrador es incorrecta.

Quise decir: traté de utilizar el sudo para realizar tareas de administración, habiendo iniciado sesión como usuario.

Ah, vale. ¿Pero con la contraseña del administrador o del usuario? Lo primero es incorrecto. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+Z9gACgkQtTMYHG2NR9VungCgmW26qfSUGi24X8oCA1oYpUh4 LAUAn2eC36CBIf26dyJUvitSVTfcKHRo =eifT -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 22:18 -0200, Gabriel escribió:

Carlos E. R. escribió:

...

...

Sé algo de C, C++ y Java ... no me considero programador como tal, solo que he tenido que aprender algunas cosas a fuerza, para resolver algunos retos que me han presentado. ¿Crees que un nivel básico pueda servir para lograr lo que quiero?

No lo se. Tampoco tengo apenas experiencia programando para linux, así que no puedo estimarlo. Y desde luego tengo muy poca idea de las consideraciones de seguridad al programar, que es lo importante aquí. Gabriel te podrá decir algo más.

Pero con lo mal que te llevas con los manuales, mal te veo :-p

No sería tan sencillo y hay que tener mucho cuidado con el tema seguridad, ya que estarías corriendo algo como super-usuario que esta escuchando peticiones de cualquiera, independientemente de la forma de comunicación.

Apparmour... para paliar un poco. A mi me daría yuyu. Me da. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+c2sACgkQtTMYHG2NR9UPUACfX6thybhRztlGK3lrAKNVYXNR pToAn12gk1vbZqYVpApK2y1BzLZrWW0H =X1fw -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gabriel escribió:

RLNIN escribió:

...

...

...

1. ¿Esto implica que debo ingresar al servidor remoto como usuario1? Sip. Va a ser que no: el ingreso está restringido sólo para el usuariox. :-S

Puede que deba leerme mejor el hilo :), pero porque motivo sólo pueden acceder con el usuariox ?? No veo ningún motivo técnico, ni siquiera si se usara samba[1], al fin y al cabo para lo que quieres hacer, el usuarioN debe existir en el sistema.

Pensándolo bien, samba ni siquiera entraría en el medio, sí o sí el ingreso lo harías por ssh, por lo tanto, cualquier usuario podría iniciar una sesión, a menos que agregues restricciones al ssh, lo cual serviría sólo para complicarte la vida :D - -- Kind regards. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREIAAYFAkj+cOUACgkQNHr4BkRe3pLcogCgoKZ5b0LD/mVMLNbHSL8aqL+d D7cAn2TVfNE3IXAV6M3WJf1Iuug1KFSt =CH3N -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2008-10-21 a las 16:17 -0500, RŌNIN escribió:

Así parece ... lo cual me lleva a los orígenes de éste rollo:

1. ¿cómo hacer que el usuario1 ejecute el comando chown como si fuera el administrador?.

Te lo puse ayer. A ver, que lo busco... repito y explico: usuario1 ALL=(root) /bin/chown usuario1 /path/* usuario2 ALL=(root) /bin/chown usuario2 /path/* usuario3 ALL=(root) /bin/chown usuario3 /path/* usuario4 ALL=(root) /bin/chown usuario4 /path/* OPERADORES ALL=(root) /bin/chown generico /path/* ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | +--+--+--+---+---+---+ | | | comando exacto que pueden ejecutar | | | | | \ en qué usuario se convierten | | | \ desde donde | \ que usuarios pueden ejecutarlo y para ejecutar deberías usar: sudo /bin/chown usuario1 /path/prueba.txt y a la inversa sudo /bin/chown generico /path/prueba.txt Y tienes que probarlo, yo no lo he hecho - obviamente >:-)

2. ¿cómo hacer que al ejecutar el comando chown, no pida la contraseña del administrador, sino la del usuario1?.

También te lo dijimos.

De veras que ya tengo agotamiento mental por cuenta de ésto ... no entiendo nada :-(

Te veo estudiandote los manuales >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+TFoACgkQtTMYHG2NR9XaDgCfaqakx12V2o8ckeh5MPcE13TG 8K4AnjhRSZYbGKLKt5+T/q2yYDOBLxIi =Dd1L -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2008-10-21 a las 14:38 -0500, RŌNIN escribió:

...

Claro. Sólo root puede cambiar propietarios arbitrariamente. Observa:

cer@nimrodel:~> l pruebas.txt - -rw-r--r-- 1 cer users 0 2008-10-21 20:08 pruebas.txt cer@nimrodel:~> chown cer2 pruebas.txt chown: changing ownership of `pruebas.txt': Operation not permitted cer@nimrodel:~> su cer2 Password: cer2@nimrodel:/home/cer> chown cer2 pruebas.txt chown: changing ownership of `pruebas.txt': Operation not permitted cer2@nimrodel:/home/cer>

Caray ... tu ejemplo ha sido MUY ilustrativo ... |8-)

Pues no te creas, me lo pensé cuando estaba anoche conciliando el sueño. No estaba seguro de cómo se iba a comportar, así que lo probé. Debías de haberlo probado tú: diseña un funcionamiento, y prueba los comandos antes de liarte con el sudo.

...

Para nada, ya te lo dije: el "su" no tiene nada que ver con "sudo".

Está bien ... ya sabes como es esto: la bestia tira para el monte y el hombre para la ciudad; ya no vuelvo al monte :-$

...

Estudiate el manual, te van las habichuelas en ello >:-)

No de nuevo ... !!!!! Qué pesadilla !!!! =-|

Ya ví tu sonrisa malévola ... :-P

:-) Pero es que es verdad. Yo te puedo guiar con sudo porque me he leído el manual, aunque no lo he comprendido entero. Si me preguntas algo complicado, me lo tengo que estudiar para responderte. Así que debes intentar leerlo tú.

PD:

1. No pude ver el último mensaje de Camaleón como respuesta a mi caso , ¿alguien me lo reenvía, por favor?.

Ya lo dije el otro dia: esos mensajes los puedes ver sin problemas en el archivo. ¿Que donde está el archivo? Deberías sabertelo de memoria :-P lists.opensuse.org

2. Si alguien puede colaborarme indicándome dónde/qué debo toquetear para que el sudo me quede para que lo requiero, lo agradezco inmensamente. (Estoy hasta los [CENSURADO] de las vueltas y revueltas con todo lo que habla de sudo ... sorry) :-(((

Te lo puse ayer, pero las pruebas y las peleas te las dejo a tí :-p - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkj+SXMACgkQtTMYHG2NR9XyWwCY04SmxvmS8dzMjoZ+4dP4y7gS xgCfV+pwbsTx/oznp94NKwIb/d+t8RY= =XW4b -----END PGP SIGNATURE-----

Hola a tod@s: El día 21 de octubre de 2008 13:15, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

No puedes.

De acuerdo ... ni modos :-(

Con sudo. No tienes más narices. Olvídate del "su".

Muy bien: su ... patada en el [CENSURADO], sudo ... tienes un nuevo amigo :-) Y ahora ... cómo le hago con el sudo ? :'-( Quedo a la espera de sus comentarios / indicaciones / sugerencias . Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s:

Te puse una posible configuración ayer.

Agregué a usuario1 al grupo sudo e intenté: usuariox@testserver:~$sudo chown usuario1 prueba.txt Pide la [CENSURADO] clave del usuariox o del administrador !!!!! usuariox@testserver:~$sudo -u usuario1 chown usuario1 prueba.txt Vuelve a pedir la [CENSURADO] clave del usuariox o del administrador !!!!! Me surge una más: ¿Dónde está la filosofia KISS en ésto? Ya no sé qué hacer y el tiempo empieza a jugar en mi contra ... ayuda, por favor. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 19:46 -0200, Gabriel escribió:

ejecuta script TAKE <archivo> ... ejecuta script RELEASE <archivo> ... Es bastante simple, no es seguro, pero es bastante simple.

Añadir un semáforo para que ni TAKE ni RELEASE se puedan ejecutar si alguien ya lo está ejecutando. O aborta o espera. Refinamiento: semáforo dependiente del fichero deseado. Liandola más: pueden ser el mismo script físico con symlinks de cambio de comportamiento, plan ip-up/ip-down. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+UBsACgkQtTMYHG2NR9WrQACgkfZtIkU/NKhMMwtiZHywLEYJ UOsAnAv5PP+nxQY08qujJVdLDLMsYstd =4UO1 -----END PGP SIGNATURE-----

Hola a tod@s: El día 21 de octubre de 2008 16:51, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Para hacer eso tendrías que hacer primero "su" a usuario1, para ser 'usuario1'.

Lo he hecho: usuariox@testserver:~$ su usuario1 Password: $ Y qué crees ?: $ who usuariox pts/0 2008-10-21 17:06 (testserver.local) $ Aún así, continúo: $ sudo chown usuario1 prueba.txt La comprobación: $ ls -rw-r--r-- 1 usuario1 usuariox 29 2008-10-21 14:47 prueba.txt Hasta aquí todo ha ido bien ... y ahora, la puntada final: Si tengo una rutina de éste estilo: #bin/bash USUARIO1=usuariox echo -e "\033[1;32mINTRODUZCA SU IDENTIFICACION\033[0m" read USUARIO2 OWNER=$(stat -c %U $ARCHIVO) if [ "$OWNER" = "$USUARIO1" ]; then sudo chown $USUARIO2 $ARCHIVO OWNER=$(stat -c %U $ARCHIVO) echo -e "\033[1;33mEL ARCHIVO HA SIDO BLOQUEADO PARA $OWNER\033[0m\n" else OWNER=$(stat -c %U $ARCHIVO) echo -e "\033[1;31mEL ARCHIVO HA SIDO BLOQUEADO POR $OWNER\033[0m\n" fi Mis preguntas: 1. ¿Cómo automatizar lo que he hecho manualmente y he descrito ? ... me lo pregunto es porque hace un cambio de shell o algo así (no sé mucho de ésto) y ahí no sé como mantener la secuencia y regresar a la shell inicial. 2. Además, ¿como hago la comprobación de la clave del usuario1 (para evitar fraudes)?.

Tomatelo con calma... estás tratando de diseñar algo, así que tienes que probar. Si algo no existe, o lo fabricas, o tomas otra ruta, o renuncias a hacerlo.

Bien, pero si las pruebas me dieran resultados positivos y mis jefes no me presionaran tanto ... me sentiría un poco mejor. Estoy tratando de fabricar y buscar alternativas, pero francamente no doy más ... y lo de renunciar, con éste desempleo rampante lo quisiera pero no puedo. Así que sigo a la espera de su invaluable orientación y ayuda. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: Veo que se ha armado un rollo con ésto ... y no sé si es porque no me he explicado adecuadamente, así que iré contestando a cada colister@ que se ha tomado la molestia de interesarse por mi caso y ha invertido algo de su tiempo para darme una opinión/sugerencia/observación: El día 17 de octubre de 2008 18:35, Shinji Ikari escribió:

Yo como usuario doméstico no entiendo lo que has escrito -_- JO, y es que soy un usuario doméstico. Que tal te iría si en lugar de usar chown usas chgrp y los usuarios pues tienen sus grupos organizados.

A éste punto, no puedo separar los usuarios en grupos, puesto que todos los winusuarios pertenecen al mismo departamento y requieren acceder/compartir la misma información.

-_- Bueno yo no soy experto en esas cosas. =/ Sugiero esperar por la gente que sabe de esas cosas. Y espero que no se mareen con la explicación. =P

Resulta fácil de representar en lápiz y papel?

Deja lo intento: Usuario genérico = usuariox. Winusuario1 = usuario1. Winusuario2 = usuario2. 1. El winusuario1 ingresa al sistema remoto (GNU/Linux) con la identidad del usuario genérico. 2. El winusuario1 requiere que el archivo prueba.txt solo pueda ser editado por él mismo. 3. El winusuario1 activa la rutina de bloqueo (con su propia identidad, la de winusuario1) y como resultado se obtiene que el archivo prueba.txt, pasa de tener de propietario al usuario genérico, a tener de propietario al winusuario1 (y procede a editarlo). 4. El winusuario2 ingresa al sistema remoto (GNU/Linux) con la identidad del usuario genérico. 5. El winusuario2 requiere que el archivo prueba.txt solo pueda ser editado por él mismo. 6. El winusuario2 activa la rutina de bloqueo (con su propia identidad, la de winusuario2) y como resultado se obtiene un error (porque el archivo tiene de propietario al winusuario1) ... y procede a activar la rutina de desbloqueo (con su propia identidad, la de winusuario2), que a su vez da error, por cuanto el winusuario2 no es propietario del archivo prueba.txt. 7. El winusuario1 termina de editar el archivo prueba.txt y activa la rutina de desbloqueo (con su propia identidad, la de winusuario1) y como resultado se obtiene que el archivo prueba.txt, pasa de tener de propietario al winusuario1, a tener de propietario al usuario genérico (y cualquier otro winusuario puede proceder a bloquearlo para su uso, siguiendo la rutina desde el punto 3).

Esto se refiere al anterior problema con el IDE y repositorios de archivos de los programadores? -_-

Así es ... es la manera más artesanal que encontré para dar la solución que se me pidió implementar.

los archivos tienen permisos UGO, no? los primeros son del usuario, luego viene lo del grupo y luego los demás. es de suponer también que el archivo está rwxr--r-- o tal vez rw------- (o puede intentar solucionarlo por ese método, tal vez)

Todos los usuarios están en el mismo grupo y como te decía inicialmente, deben boder bloquear/desbloquear/acceder a la misma información ... pero hice unas rutinas para que un usuario diferente al que bloquea un archivo, no pueda desbloquearlo.

Luego me fijo en el primer comando que indico: usuariox@testserver:~$su usuario1 chown usuario1 nombre_archivo pero es posible cambiar los derechos de un archivo de un usuario que tiene el mismo nivel que otro usuario?

Eso lo impide/administra las rutinas creadas y que he mencionado.

El archivo pertenece a un grupo de usuarios, y quiere que se bloqueen los derechos de escritura cuando un usuarios decida modificarlo y mientras lo tenga abierto los demás no puedan verlo y modificarlo. Pero como saber cuando el usuario termino de modificar el archivo? hay manera de saber el estado de un archivo? es decir si esta cerrado o hay nadie con el editor abierto editándolo? Pero creo que al abrirse un archivo se carga en memoria y no se escriben los cambios hasta que se pone el save, no?

No se hace de esa manera, existe una rutina que activas cuando vas a editarlo (la de bloqueo), existe una que activas cuando terminas de editar el archivo (la de desbloqueo) y otra que te indica quien tiene bloqueado el archivo o lo que es lo mismo: quien es el usuario propietario del archivo (la de consulta).

Como asesor me muero de hambre, espero no haberle confundido más. Esperar a comentarios más valiosos es la mejor opción. =/

No hay cuidado, espero no haberte confundido más con mi explicación; gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 23:15 +0200, Camaleón escribió:

Pregunta... ¿sudo te pide nombre de usuario y contraseña o sólo la contraseña del usuario que ha iniciado la sesión?

Debe pedir la contraseña del usuario propietario de la sesión. Hay una excepción, una configuración provisional que se usa durante la instalación, que pide la contraseña de root; pero es la configuración con la que viene preparada la suse.

Según el manual (man sudoers), para solicitar la contraseña a un usuario (o grupo definido como alias) podrías poner:

Defaults:OPERADORES authenticate

Pero si todos han iniciado sesión con el mismo usuario (usuariox) y

Entonces pedirá la contraseña de "usuariox".

sudo no pide login/password... hum, salvo que uses la opción de "runas_list|user" pues no veo cómo hacerlo :-?

Yo es que me he perdido un poco, la explicación era tan larga que me perdí. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj7qzMACgkQtTMYHG2NR9VjmACfbwu++eEX8gnAbN1XvXIIHQNL z0gAnjkB08kyu5r4ZTqxgcj6CdAKWve4 =txpL -----END PGP SIGNATURE-----

??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 22:29 -0300, Ciro Iriarte escribió:

Con gmail veo vacío el email de Camaleon....

Eso es un bug conocido de gmail, y hace poco Camaleón mandó un correo donde explicaba el porqué. Leelo en el archivo de la lista. Y en el archivo puedes ver esos correos que gmail no te deja ver.

Que es lo que busca hacer?, sudo permite hacer cosas como "Permitir a Camaleon correr /usr/local/sbin/orastart.sh como el usuario oracle", o "Permitir a Camaleon ejecutar /usr/bin/passwd como root, pero sin poder cambiar la contraseña de root" , se suele usar para delegar ciertas tareas administrativas a los operadores que monitorean un sistema...

Todo eso lo se y no es eso lo que preguntaba yo. Además, no es Camaleón quien pregunta, sino una de los que responde. Mi problema es no entender exactamente qué problema tiene el que tiene el problema con sudo, porque me he perdido en la explicación del problema. ¿Capishi? >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj74kgACgkQtTMYHG2NR9XOhwCfXMUUs84YirUTAyDUCWQpVaoW X0YAn32tRlkgAaZUMkDqW2C+/P229twl =4wsT -----END PGP SIGNATURE-----

??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 22:49 -0300, Ciro Iriarte escribió:

...

Todo eso lo se y no es eso lo que preguntaba yo. Además, no es Camaleón quien pregunta, sino una de los que responde.

Segun tus quotes de su mail ("Camaleón escribió:") el tb tiene preguntas.

Lee su correo en el archivo de la lista y lo verás - y no es "el", por cierto :-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj75gAACgkQtTMYHG2NR9UjxgCffJO4ci5CENhxHVkcaCB+R/BU idsAnjqMpATWETIylt/2kQDIug0Y2Dtb =4+PK -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: ??l 2008-10-17 a las 22:54 -0400, Ciro Iriarte escribió:

Hmm, la verdad es que la solución es algo hedionda porque un usuario podría realizar el cambio de permisos mientras que otro esta modificando el archivo....

En la idea original, que se la di yo (mira atrás en el archivo una o dos semanas), otro usuario no puede cambiar el propietario del fichero porque no es suyo, y no es root. Es decir, el permiso es cambiado por un programa de control que corre como root y sí puede cambiarlos, pero cualquiera entrando por otro lado no podría escribir los ficheros. Ahora, que sí podría leerlo dos usuarios, y sólo uno escribir --> cacao. Hay que hacerlo con un script, desde luego, y cada usuario debe entrar con un login distinto, el mismo usuario con el que trabaje para todo. Y sí, es una solución hedionda. Totalmente de acuerdo. Ya puestos, si se entra con un script, el script también puede crear un lockfile tipo fichero:propietario, y rechazar abrir si no es el propietario. Lo mismo da.

No esta clara la imagen global de la solución, podrían usar SVN y lockfiles a ese nivel...

Deberías releer los correos anteriores de R#NIN, porque eso es precisamente lo que tiene -- pero resulta que sus señores usuarios programadores son tan despistados que se olvidan de subir el trabajo del dia al CVS, y se arman cacaos de cuidado >:-) Y en vez de despedir los programadores (y al jefe que los contrató y no es capaz de imponer orden y disciplina y método) le mandan a este hombre que implemente soluciones como esa de los bloqueos. Ya les vale. En fin, calma, seguro que si logra implementarla, a esos programadores se les olvidará otra cosa más grave. Menos mal que me pilla lejos.

:-P

Si no hay repositorios de por medio, lo ideal sería crear un script que llame al IDE o editor y utilizar lockfiles para asegurarse de no modificar concurrentemente un archivo. Con todos los archivos pertenecientes a un grupo comun a los usuarios q deben modificarlos.

Los editores no bloquean los archivos al abrirlos. Sólo durante el acto de grabar. Ah! Te refieres a que lo haga manualmente en un script, claro; justo lo que acabo de decir más arriba sin darme cuenta O:-)

-------editar.sh-------- #!/bin/bash -u

LOCKFILE=${1}.lock

- -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj5r+IACgkQtTMYHG2NR9VdYACcDArbgTQbWd+CWWHOnjjiB15/ nIcAn3xxZiRiFULRfcX7wghjd1eHYtIa =JIRu -----END PGP SIGNATURE-----

??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 14:44 -0300, Ciro Iriarte escribió:

...

Hay que hacerlo con un script, desde luego, y cada usuario debe entrar con un login distinto, el mismo usuario con el que trabaje para todo.

Por lo que entendi de su peticion, el piensa cambiar los permisos mediante sudo, o sea, darle privilegios a los mismos usuarios para cambiar los permisos de los archivos en cuestion antes de empezar a trabajar...

No exactamente. Los usuarios no tienen permiso para cambiar los permisos ni para editar los archivos; pero al ejecutar el script de control el permiso del fichero que quieren editar cambia a ser suyo, con lo que lo pueden editar y ningún otro puede hacerlo. Al acabar, el script vuelve a ponerlo al nombre por defecto, que no se quien será. Su idea actual no he terminado de comprenderla, me pone expeso :-)

Y si, en ciertos casos los problemas son más politicos que tecnicos...

Absolutamente. En este caso se trata de un problema de dirección y gestión. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj7fOUACgkQtTMYHG2NR9VgWgCfSMn28kg/CR+OHwq8xRKGEKQ7 OdYAnivKYPfdy3fWimA1bD+mfW7Hkxtu =tD97 -----END PGP SIGNATURE-----

??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 16:52 -0300, Ciro Iriarte escribió:

...

No exactamente.

Los usuarios no tienen permiso para cambiar los permisos ni para editar los archivos; pero al ejecutar el script de control el permiso del fichero que

Pero quien ejecuta el script?, no creo que el reciba peticiones por email para cambiar los permisos cada vez que alguien quiera editar algo :D

Si son los mismos usuarios mediante sudo, quien evita que yo haga "sudo cambiar_owner.sh /ruta/archivo" mientras vos editas el mismo archivo?

No, porque el script no lo admite hacer. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj7kpgACgkQtTMYHG2NR9UrPwCfZkD2kgCJK4C8OQZh6grLUmc+ 0C8AoIsUsVnaok9qm3vK1UuzyD+gKtJh =OVi3 -----END PGP SIGNATURE-----

??----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-19 a las 17:08 -0300, Ciro Iriarte escribió:

...

...

Si son los mismos usuarios mediante sudo, quien evita que yo haga "sudo cambiar_owner.sh /ruta/archivo" mientras vos editas el mismo archivo?

No, porque el script no lo admite hacer.

Pero no hay script hecho (mal ejemplo mio)... hasta ahora solo tenemos el uso de chown con sudo segun el mail original...

Claro, el script lo tiene que hacer; y el problema con el sudo no lo entendí exactamente. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj7qbYACgkQtTMYHG2NR9VhUACdFcwEGrsvkD6z4ndHHjezS1d9 ZdkAn3G89FazDii8cS7sNLzCOggIFXA2 =cuA5 -----END PGP SIGNATURE-----

Hola a tod@s: El día 17 de octubre de 2008 21:54, Ciro Iriarte escribió:

Hmm, la verdad es que la solución es algo hedionda porque un usuario podría realizar el cambio de permisos mientras que otro esta modificando el archivo....

No lo creo, ya que las rutinas tienen variables comparativas: 1. Solicitan la identidad del usuario que activa la rutina 2. Mediante sudo, certifican la clave del usuario que se ha identificado antes (para evitar fraudes). 3. Si la identidad del usuario corresponde al propietario del archivo especificado, se realiza el cambio (bloqueo/desbloqueo); en caso que las identidades (usuario y propietario) no correspondan, las rutinas sólo presentan mensajes informativos o de error y no hacen cambio alguno.

Para hacer funcionar sudo:

* Comenta "Defaults targetpw" en /etc/sudoers (en caso de que este) * Cambia la regla a "OPERADORES ALL=(root) CAMBIAR" * Ejecución de cambio de permiso: "sudo chown usuario /path/al/archivo"

El tópico del primer asterisco no existe en mi /etc/sudoers Cambié el segundo tópico tal cual me indicas pero ... Al ejecutar la instrucción del tercer tópico, solo realiza el cambio si digito la contraseña del administrador, no la del winusuario (GGGRRRRR!!!!!!!!!).

No esta clara la imagen global de la solución, podrían usar SVN y lockfiles a ese nivel...

De aquí en adelante ... descartado, por lo que ya he expuesto en respuestas anteriores. Gracias por tu tiempo e interés. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 20 de octubre de 2008 15:11, Ciro Iriarte escribió:

El día 20 de octubre de 2008 13:25, RŌNIN escribió:

...

Hola a tod@s:

...

Para hacer funcionar sudo:

* Comenta "Defaults targetpw" en /etc/sudoers (en caso de que este) * Cambia la regla a "OPERADORES ALL=(root) CAMBIAR" * Ejecución de cambio de permiso: "sudo chown usuario /path/al/archivo"

El tópico del primer asterisco no existe en mi /etc/sudoers Cambié el segundo tópico tal cual me indicas pero ... Al ejecutar la instrucción del tercer tópico, solo realiza el cambio si digito la contraseña del administrador, no la del winusuario (GGGRRRRR!!!!!!!!!).

Eso es sintoma de que targetpw esta definido....

Ciro

Olvide que tb debe ser comentada la linea que le sigue, sino todos pueden hacer cualquier cosa como cualquier usuario. #Defaults targetpw # ask for the password of the target user i.e. root #ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! Atte Ciro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-20 a las 17:50 -0500, RŌNIN escribió:

Este es el contenido de mi /etc/sudoers:

# /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. #

Defaults env_reset

# Uncomment to allow members of group sudo to not need a password # %sudo ALL=NOPASSWD: ALL

# Host alias specification

# User alias specification User_Alias OPERADORES=usuario1,usuario2,usuario3 # Cmnd alias specification Cmnd_Alias CAMBIAR=/usr/bin/chown # User privilege specification root ALL=(ALL) ALL

# Members of the admin group may gain root privileges %admin ALL=(ALL) ALL

OPERADORES ALL=(root) CAMBIAR

Como verás, ninguna de las dos líneas que me indican, aparecen para comentarlas ... de cualquier manera, ¿ las agrego y las comento ?.

Vale... pero el problema era que no usabas sudo, sino su. Sin embargo, date cuenta que la linea: OPERADORES ALL=(root) CAMBIAR permite a cualquier operador cambiarse (chown) a cualquier otro usuario, si pueden loguearse. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj9EUQACgkQtTMYHG2NR9XdXACcD7MXVnEs4X/uJCbDYbrSUu7G TQcAnRvRjFfo6BQhqyIOkMqtv28cadJN =G4jW -----END PGP SIGNATURE-----