Muchísimas gracias por la ayuda, ya logré avanzar un poco. De momento lo que hice es en las máquinas con las que estoy probando les configuré a todas el mismo userID para cada usuario en común. Con eso logré que cuando un determinado usuario accede a una carpeta en NFS pueda escribir solamente si está en su home (antes el usuario A por ejemplo podía escribir en la carpeta del usuario C, lo cual sucedía porque tenían el mismo user ID). La duda que me surge ahora es si en un determinado momento accedo con el usuario Z por ejemplo, que no tenga un home en el servidor pero su user ID coincida con el de A. Lo que pasa en ese caso es que Z va a poder escribir en la carpeta de A (me explico o hice mucho lío???). Aver si me explico mejor: A, B y C son usuarios que tienen un home en el servidor, en el cual la carpeta entera /home es la que se exporta. Si yo accedo desde una PC cliente con el usuario A, B o C y siempre que coincidan los user ID va trodo perfecto, es decir cada usuario accede a su home y tiene permiso de escritura (así configuré yo la exportación del directorio). Pero ahora si accedo desde una PC con el usuario Z (el cual no tiene una cuenta creada en el servidor) pero que su user ID es el mismo que el de A o B o C este va a poder escribir en la carpeta del usuario cuyo ID coincida no??? Esto estimo que es un problema. Lo mismo que si en una de las PCs que accedo tengo los IDs "cruzados", como me pasó al principio, osea A escribe en el home de B y C en el de A por ejemplo, osea un lío total. Hay alguna manera de solucionar esto o esto siempre es así??? (perdón mi ignorancia). Ahora por último, con respecto a esto: /home<->*(fsid=0,root_squash,rw,sync,no_subtree_check) Me decís que "se refiere al UUID de la partición exportada. El valor que está en /dev/disk/by-uuid". Nuevamente perdón por mi ignorancia, pero podrías ser un poco más específico??? Osea que pasa si no pongo ese parámetro o si cambio arbitrariamente el valor. Muchas gracias por su ayuda, la verdad que ya logré un avance importante. Si conocen alguna documentación interesante para leer les agradecería que la recomienden. Yo ahora estoy con un howto, lo que viene en el manual de OS y la man page de exports ya la leí, pero todavía como verán me falta entender varias cosas. Saludos y muchas gracias. Mauro. Con respecto a: Carlos E. R. escribió:

El 2009-12-21 a las 16:47 -0200, Mauro Antivero escribió:

...

Hola gente cómo les va? Mi duda en este caso es la siguiente:

...

Estoy armando un servidor en el cual quiero compartir uno o más directorios mediante NFS.

...

Para probar rápidamente lo configuré usando YAST siguiendo los pasos que aparecen en el manual ("Reference Guide") de OS11.2 (el cual obviamente es el SO que estoy usando).

...

Luego en una de las posibles PCs clientes monté este directorio compartido primero usando YAST y luego a mano, funcionando en ambos casos sin problemas.

...

El tema es que cuando accedo en la PC cliente a la carpeta compartida como "mauro" (mi usuario) puedo escribir tanto en mi home (la carpeta que compartí de momento para hacer pruebas es /home, con varios usuarios dentro) puedo escribir en mi home (/home/mauro) pero no en los demás, lo cual es totalmente aceptable...

...

Pero cuando le digo a un compañero que monte el directorio compartido y pruebe como le funciona sucede que él no puede escribir en su home pero si en el mío!!!

En el NFS los permisos de acceso van como en linux: por el número del usuario. El usuario 1500 (pepe) cliente podrá acceder a los ficheros del usuario 1500 (juan) del servidor. El nombre de los usuarios no importa para nada, sólo su numero. Y no es posible mapearlos.

Es decir, los usuarios han de tener el mismo número en todas las máquinas que usen y en el servidor.

...

Estoy leyendo el manual de exports y entendí algunas cosas más, pero todavía no doy en la tecla con el asunto. La línea que tengo configurada en /etc/exports es la siguiente:

...

/home<->*(fsid=0,root_squash,rw,sync,no_subtree_check)

...

De esas opciones la que "menos entiendo" (las demás "creo entenderlas") es la de fsid, leí la man page de exports pero sigo sin entender para que sirve.

Se refiere al UUID de la partición exportada. El valor que está en /dev/disk/by-uuid.

-- Saludos Carlos E. R.

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

Saludos. Si deseas manejar NFS y tener permisos de acceso por usuario debes hacer lo siguiente: * NFS v4: debes usar kerberos + ldap ... en otras palabras todo un sistema de autenticacion centralizado, que por lo que intuyo no vale la pena montarlo en el ambiente en el que haces el despliegue. Ademas montarlo bien te va a tomar una buena cantidad de horas de estudio y pruebas. * NFS versiones anteriores: usar NIS... es extremadamente simple de configurar (2 horas de trabajo leyendo todo con calma) y funciona perfecto. Puesde tener incluso el home de todos los usuarios en el servidor NFS y solo necesitas crear usuarios en el servidor, ya que NIS se encarga de propagar los cambios en los clientes. Mi recomendacion por ende es: en un ambiente sencillo y controlado usa NFS+NIS. Lo he desplegado en un lugar con 30 clientes Linux y un servidor NIS/NFS y funciona sin problemas. Desde que lo monte, salvo por un bug de RPC propio de Ubuntu LTS server que se soluciono cambiando de distribucion, no ha molestado para nada. Hasta la proxima. Carlos. 2009/12/22 Mauro Antivero

Muchísimas gracias por la ayuda, ya logré avanzar un poco.

De momento lo que hice es en las máquinas con las que estoy probando les configuré a todas el mismo userID para cada usuario en común. Con eso logré que cuando un determinado usuario accede a una carpeta en NFS pueda escribir solamente si está en su home (antes el usuario A por ejemplo podía escribir en la carpeta del usuario C, lo cual sucedía porque tenían el mismo user ID).

La duda que me surge ahora es si en un determinado momento accedo con el usuario Z por ejemplo, que no tenga un home en el servidor pero su user ID coincida con el de A. Lo que pasa en ese caso es que Z va a poder escribir en la carpeta de A (me explico o hice mucho lío???). Aver si me explico mejor:

A, B y C son usuarios que tienen un home en el servidor, en el cual la carpeta entera /home es la que se exporta.

Si yo accedo desde una PC cliente con el usuario A, B o C y siempre que coincidan los user ID va trodo perfecto, es decir cada usuario accede a su home y tiene permiso de escritura (así configuré yo la exportación del directorio).

Pero ahora si accedo desde una PC con el usuario Z (el cual no tiene una cuenta creada en el servidor) pero que su user ID es el mismo que el de A o B o C este va a poder escribir en la carpeta del usuario cuyo ID coincida no??? Esto estimo que es un problema. Lo mismo que si en una de las PCs que accedo tengo los IDs "cruzados", como me pasó al principio, osea A escribe en el home de B y C en el de A por ejemplo, osea un lío total.

Hay alguna manera de solucionar esto o esto siempre es así??? (perdón mi ignorancia).

Ahora por último, con respecto a esto:

/home<->*(fsid=0,root_squash,rw,sync,no_subtree_check)

Me decís que "se refiere al UUID de la partición exportada. El valor que está en /dev/disk/by-uuid".

Nuevamente perdón por mi ignorancia, pero podrías ser un poco más específico??? Osea que pasa si no pongo ese parámetro o si cambio arbitrariamente el valor.

Muchas gracias por su ayuda, la verdad que ya logré un avance importante. Si conocen alguna documentación interesante para leer les agradecería que la recomienden. Yo ahora estoy con un howto, lo que viene en el manual de OS y la man page de exports ya la leí, pero todavía como verán me falta entender varias cosas.

Saludos y muchas gracias.

Mauro.

Con respecto a: Carlos E. R. escribió:

...

El 2009-12-21 a las 16:47 -0200, Mauro Antivero escribió:

...

Hola gente cómo les va? Mi duda en este caso es la siguiente:

...

Estoy armando un servidor en el cual quiero compartir uno o más directorios mediante NFS.

...

Para probar rápidamente lo configuré usando YAST siguiendo los pasos que aparecen en el manual ("Reference Guide") de OS11.2 (el cual obviamente es el SO que estoy usando).

...

Luego en una de las posibles PCs clientes monté este directorio compartido primero usando YAST y luego a mano, funcionando en ambos casos sin problemas.

...

El tema es que cuando accedo en la PC cliente a la carpeta compartida como "mauro" (mi usuario) puedo escribir tanto en mi home (la carpeta que compartí de momento para hacer pruebas es /home, con varios usuarios dentro) puedo escribir en mi home (/home/mauro) pero no en los demás, lo cual es totalmente aceptable...

...

Pero cuando le digo a un compañero que monte el directorio compartido y pruebe como le funciona sucede que él no puede escribir en su home pero si en el mío!!!

En el NFS los permisos de acceso van como en linux: por el número del usuario. El usuario 1500 (pepe) cliente podrá acceder a los ficheros del usuario 1500 (juan) del servidor. El nombre de los usuarios no importa para nada, sólo su numero. Y no es posible mapearlos.

Es decir, los usuarios han de tener el mismo número en todas las máquinas que usen y en el servidor.

...

Estoy leyendo el manual de exports y entendí algunas cosas más, pero todavía no doy en la tecla con el asunto. La línea que tengo configurada en /etc/exports es la siguiente:

...

/home<->*(fsid=0,root_squash,rw,sync,no_subtree_check)

...

De esas opciones la que "menos entiendo" (las demás "creo entenderlas") es la de fsid, leí la man page de exports pero sigo sin entender para que sirve.

Se refiere al UUID de la partición exportada. El valor que está en /dev/disk/by-uuid.

-- Saludos        Carlos E. R.

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

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

jaime velez wrote:

El 22/12/09 10:32, Carlos Martinez escribió:

...

Saludos.

Si deseas manejar NFS y tener permisos de acceso por usuario debes hacer lo siguiente:

* NFS v4: debes usar kerberos + ldap ... en otras palabras todo un sistema de autenticacion centralizado, que por lo que intuyo no vale la pena montarlo en el ambiente en el que haces el despliegue. Ademas montarlo bien te va a tomar una buena cantidad de horas de estudio y pruebas.

de pronto solo ldap.. kerberos lo veo como exagerado.. propongo ldap y NFS, montar ldap en opensuse... 15 minutos.. ( y creo que exagero) si los clientes son todos opensuse, hacer que se conecten al directorio ldap.. 2 minuticos por cliente ( y tambien creo que exagero) con esto tienes una base de datos centralizada de usuarios y grupos ( todo manejable desde yast) y el resto.. lo que te demores con NFS.. lo bueno de ldap... cualquier servicio adicional es relativamente facil de pegarlo a ldap.. incluyendo samba y clientes windows (cosa que es imposible con nis).. mejor dicho .. el tiempo que le pierdas a ldap.. de verdad no es perdido.. no es tampoco tan complejo como lo pintan... no por lo menos en opensuse..

Jaime V

Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos por un servidor AD ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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

jaime velez wrote:

El 22/12/09 11:18, carlopmart escribió:

...

...

El 22/12/09 10:32, Carlos Martinez escribió:

...

Saludos.

Si deseas manejar NFS y tener permisos de acceso por usuario debes hacer lo siguiente:

* NFS v4: debes usar kerberos + ldap ... en otras palabras todo un sistema de autenticacion centralizado, que por lo que intuyo no vale la pena montarlo en el ambiente en el que haces el despliegue. Ademas montarlo bien te va a tomar una buena cantidad de horas de estudio y pruebas.

de pronto solo ldap.. kerberos lo veo como exagerado.. propongo ldap y NFS, montar ldap en opensuse... 15 minutos.. ( y creo que exagero) si los clientes son todos opensuse, hacer que se conecten al directorio ldap.. 2 minuticos por cliente ( y tambien creo que exagero) con esto tienes una base de datos centralizada de usuarios y grupos ( todo manejable desde yast) y el resto.. lo que te demores con NFS.. lo bueno de ldap... cualquier servicio adicional es relativamente facil de pegarlo a ldap.. incluyendo samba y clientes windows (cosa que es imposible con nis).. mejor dicho .. el tiempo que le pierdas a ldap.. de verdad no es perdido.. no es tampoco tan complejo como lo pintan... no por lo menos en opensuse..

Jaime V Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos

jaime velez wrote: por un servidor AD ...

Saludos.

No lo veo tan claro.. en el modulo de yast .. por un lado activas NFSV4 y por otro activas o no (opcional).. seguridad GSS ( que es la que se encarga de todo lo que tiene que ver con Kerberos.. hasta donde se NFSV4 puede usar o no kerberos.. se recomienda... pero no es obligatoria...

Jaime V

p.d.. ahora no soy tan ducho en el tema.. pero lo que entiendo es que para evitar un problema de propagación de ID.. mejor tener una sola base de datos de usuarios.. eso lo da LDAP que con yast es "coser y cantar" y por otro lado compartir carpetas sin problemas de ID's.. ya hecho lo hecho con ldap.. el problemas de las ID's no exista para NFS

Es correcto: puedes usar o no kerberos. Pero si quieres controlar quien accede al recurso necesitarás que sea mediante user y pass y ahí entra kerberos ... -- CL Martinez carlopmart {at} gmail {d0t} com -- 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

jaime velez wrote:

El 22/12/09 12:07, carlopmart escribió:

...

jaime velez wrote:

...

El 22/12/09 11:18, carlopmart escribió:

...

...

El 22/12/09 10:32, Carlos Martinez escribió:

...

Saludos.

Si deseas manejar NFS y tener permisos de acceso por usuario debes hacer lo siguiente:

* NFS v4: debes usar kerberos + ldap ... en otras palabras todo un sistema de autenticacion centralizado, que por lo que intuyo no vale la pena montarlo en el ambiente en el que haces el despliegue. Ademas montarlo bien te va a tomar una buena cantidad de horas de estudio y pruebas.

de pronto solo ldap.. kerberos lo veo como exagerado.. propongo ldap y NFS, montar ldap en opensuse... 15 minutos.. ( y creo que exagero) si los clientes son todos opensuse, hacer que se conecten al directorio ldap.. 2 minuticos por cliente ( y tambien creo que exagero) con esto tienes una base de datos centralizada de usuarios y grupos ( todo manejable desde yast) y el resto.. lo que te demores con NFS.. lo bueno de ldap... cualquier servicio adicional es relativamente facil de pegarlo a ldap.. incluyendo samba y clientes windows (cosa que es imposible con nis).. mejor dicho .. el tiempo que le pierdas a ldap.. de verdad no es perdido.. no es tampoco tan complejo como lo pintan... no por lo menos en opensuse..

Jaime V Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos

jaime velez wrote: por un servidor AD ...

Saludos.

No lo veo tan claro.. en el modulo de yast .. por un lado activas NFSV4 y por otro activas o no (opcional).. seguridad GSS ( que es la que se encarga de todo lo que tiene que ver con Kerberos.. hasta donde se NFSV4 puede usar o no kerberos.. se recomienda... pero no es obligatoria...

Jaime V

p.d.. ahora no soy tan ducho en el tema.. pero lo que entiendo es que para evitar un problema de propagación de ID.. mejor tener una sola base de datos de usuarios.. eso lo da LDAP que con yast es "coser y cantar" y por otro lado compartir carpetas sin problemas de ID's.. ya hecho lo hecho con ldap.. el problemas de las ID's no exista para NFS

Es correcto: puedes usar o no kerberos. Pero si quieres controlar quien accede al recurso necesitarás que sea mediante user y pass y ahí entra kerberos ...

Pos ya me puse como canson... sigo sin verlo tan claro.. hasta donde se, kerberos es solo un mecanismo de autenticar ( decir si tu eres tu) no un mecanismo de autorizar.. (decir si tu tienes permiso a cual o cuales cosas).. todo eso mediante un mecanismo de tickets que a mi se me hace como chino avanzado... con ldap y nss/pam se puede implementar lo mismo que con ldap - kerberos pero sin la seguridad extrema..

Es correcto lo que comentas. Kerberos es un servicio de autenticación que es utilizado para entornos que precisan de autenticación distribuida. Un ejemplo: imagina que tienes un usuario pepe que precisa de acceso nfs a n servidores. basta con que hagas una única autenticación y mediante el acceso que proporciona NFSv4 ya dispondrías de acceso a esos n servidores de forma transparente. Naturalmente esto está pensado para entornos medianos y grandes y no para entornos pequeños. Ahora bien, si en tu entorno pequeño dispones de un servidor windows con AD, puedes aprovecharlo para hacer lo mismo que con kerberos-ldap. Estoy de acuerdo contigo que en un entorno pequeño, esto es matar moscas a cañonazos ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Carlos E. R. escribió:

El 2009-12-22 a las 17:18 +0100, carlopmart escribió:

...

Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos por un servidor AD

¿Que es lo que hacen ldap y kerberos?

El punto que a mi me interesa es si se puede hacer que un fichero con uid 1500 se puede servir a un cliente con uid aparente 1501 y a otro con 1502. O sea, mapear uids entre servidor y cliente. O mapear por nombre, no por uids.

Ese es el punto flojo del nfs, que tienes que tener los mismos usuarios con los mismos uids en todos los ordenadores de la red, inlcuido el servidor.

Entiendo que samba es más flexible en esto.

-- Saludos Carlos E. R.

Me parece que no es tan así, es decir, en el servidor tengo digamos el usuario "pepe" pero en la PC del usuario "Pepe" su nombre de usuario es por ejemplo "pepito", pero ambas configuradas (esto lo hice hoy) el mismo UID (antes eran distintos) y resulta que "pepito" accede a /home/pepe en el servidor mediante NFS y no me ha dado ningún problemas, es decir lee y escribe como si se tratase de su home. Osea que la "restricción" la veo de momento con el UID. Pero perdón... No fuiste vos (Carlos E.R.) el que me dijo justamente eso??? Cito lo que escribiste en un correo anterior: "En el NFS los permisos de acceso van como en linux: por el número del usuario. El usuario 1500 (pepe) cliente podrá acceder a los ficheros del usuario 1500 (juan) del servidor. El nombre de los usuarios no importa para nada, sólo su numero. Y no es posible mapearlos. Es decir, los usuarios han de tener el mismo número en todas las máquinas que usen y en el servidor. " Saludos. Mauro. -- 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

Carlos E. R. escribió:

Content-ID:

El 2009-12-22 a las 15:11 -0200, Mauro Antivero escribió:

...

Carlos E. R. escribió:

...

El 2009-12-22 a las 17:18 +0100, carlopmart escribió:

...

Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos por un servidor AD

¿Que es lo que hacen ldap y kerberos?

El punto que a mi me interesa es si se puede hacer que un fichero con uid 1500 se puede servir a un cliente con uid aparente 1501 y a otro con 1502. O sea, mapear uids entre servidor y cliente. O mapear por nombre, no por uids.

Ese es el punto flojo del nfs, que tienes que tener los mismos usuarios con los mismos uids en todos los ordenadores de la red, inlcuido el servidor.

Entiendo que samba es más flexible en esto.

Me parece que no es tan así, es decir, en el servidor tengo digamos el usuario "pepe" pero en la PC del usuario "Pepe" su nombre de usuario es por ejemplo "pepito", pero ambas configuradas (esto lo hice hoy) el mismo UID (antes eran distintos) y resulta que "pepito" accede a /home/pepe en el servidor mediante NFS y no me ha dado ningún problemas, es decir lee y escribe como si se tratase de su home.

...

Osea que la "restricción" la veo de momento con el UID. Pero perdón... No fuiste vos (Carlos E.R.) el que me dijo justamente eso??? Cito lo que escribiste en un correo anterior:

Claro, la restricción es el UID, el nombre da igual. Pero más vale que pongas todos los ordenadores con los mismos nombres y uids, o te vas ha liar más que la pata de un romano.

-- Saludos Carlos E. R. Gracias, de a poco voy entendiendo algo más, pero estoy perdido con todo lo que leo en la lista de LDAP + Kerberos :S En cuanto pueda me pongo con ese tema.

Les parece si abro otro tema denominado por ejemplo "configurar servidor NFS sencillo" y voy poniendo todas las peripecias por las que pasé? Así queda algo de referencia como para que uno que lo quiera hacer tenga más fácil el inicio. Ustedes dirán. Saludos! Mauro. -- 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

Carlos E. R. wrote:

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

El 2009-12-22 a las 17:18 +0100, carlopmart escribió:

...

Para lo que ha comentado Carlos, y con NFSv4 es necesario kerberos ... no es que sea exagerado, es que es imprescindible. Como comenté en otro correo también se puede substitur la combinación ldap+kerberos por un servidor AD

¿Que es lo que hacen ldap y kerberos?

El punto que a mi me interesa es si se puede hacer que un fichero con uid 1500 se puede servir a un cliente con uid aparente 1501 y a otro con 1502. O sea, mapear uids entre servidor y cliente. O mapear por nombre, no por uids.

Ese es el punto flojo del nfs, que tienes que tener los mismos usuarios con los mismos uids en todos los ordenadores de la red, inlcuido el servidor.

Entiendo que samba es más flexible en esto.

Pues para todo eso que comentas es por lo que se hizo NFSv4 para funcionar con kerberos y ldap: para evitar el principal problema de mapeo de usuarios entre un server o n servers ... En una arquitectura de este nivel lo que se hace es usar ldap para el tema de los uids, home, recursos, etc .. y kerberos para la autenticación distribuida, esto es: solo te autenticas una sola vez y tienes accesos a todos los recursos desde NFS a servicios web. Teneis que verlo como un todo como hace el Active Directory de Microsoft.

- -- Saludos Carlos E. R.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksxChUACgkQtTMYHG2NR9XoWACfSLG1uhABn+ll/QhKgpSqqree 2kIAn0mV/oLJ/zDrFJvDvprCt9iTBxBT =uEdH -----END PGP SIGNATURE-----

-- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Carlos E. R. wrote:

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

El 2009-12-22 a las 19:09 +0100, carlopmart escribió:

...

Carlos E. R. wrote:

...

...

¿Que es lo que hacen ldap y kerberos?

El punto que a mi me interesa es si se puede hacer que un fichero con uid 1500 se puede servir a un cliente con uid aparente 1501 y a otro con 1502. O sea, mapear uids entre servidor y cliente. O mapear por nombre, no por uids.

Ese es el punto flojo del nfs, que tienes que tener los mismos usuarios con los mismos uids en todos los ordenadores de la red, inlcuido el servidor.

Entiendo que samba es más flexible en esto.

Pues para todo eso que comentas es por lo que se hizo NFSv4 para funcionar con kerberos y ldap: para evitar el principal problema de mapeo de usuarios entre un server o n servers ...

En una arquitectura de este nivel lo que se hace es usar ldap para el tema de los uids, home, recursos, etc .. y kerberos para la autenticación distribuida, esto es: solo te autenticas una sola vez y tienes accesos a todos los recursos desde NFS a servicios web.

Teneis que verlo como un todo como hace el Active Directory de Microsoft.

Pero vamos a ver, lo que yo entiendo que hace es que defines en un servidor centralizado que juan es 1500 en todas partes, pepe es 1501 en todas partes, etc. Y luego con kerberos controlas las contraseñas y accesos también de manera centralizada.

Un apunte: kerberos solo autentica, no controla nada.

De este modo, juan es el 1500 en todos los ordenadores de la red, y no tiene problemas de acceso al directorio con uid 1500 en el servidor nfs.

Pero, que yo sepa, no permite que el usuario 1234 llamado juan de un portatil conectado a la red acceda al directorio con uid 1500 del servidor, aún dando la contraseña correcta de juan, porque juan en la red es el 1500, y está entrando con 1234. Si logra acceder, el servidor NFS sólo le daría permiso de lectura a los ficheros grabados con uid 1234, que no existen.

Si lo permite. Basta que el usuario juan del laptop se autentique como el juan de la red. Un ejemplo: kinit juan@ORGANIZACION.ORG. Para ello el juan del laptop tiene que tener configurado su cliente kerberos con los parámetros del realm kerberos. Y todavía puedes llevar el tema más lejos: relaciones de confianza entre realms kerberos, igual que hace el AD. Saludos.

- -- Saludos Carlos E. R.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksxDrgACgkQtTMYHG2NR9VsaACcC6iTWts4w10ebmkYWgHXnsVD +QgAn3ttBWIO11qJ8np8II4VH0C8CGEL =LYbR -----END PGP SIGNATURE-----

-- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Carlos E. R. wrote:

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

El 2009-12-22 a las 19:56 +0100, carlopmart escribió:

...

Carlos E. R. wrote:

...

...

Pero vamos a ver, lo que yo entiendo que hace es que defines en un servidor centralizado que juan es 1500 en todas partes, pepe es 1501 en todas partes, etc. Y luego con kerberos controlas las contraseñas y accesos también de manera centralizada.

Un apunte: kerberos solo autentica, no controla nada.

Vale.

...

...

De este modo, juan es el 1500 en todos los ordenadores de la red, y no tiene problemas de acceso al directorio con uid 1500 en el servidor nfs.

Pero, que yo sepa, no permite que el usuario 1234 llamado juan de un portatil conectado a la red acceda al directorio con uid 1500 del servidor, aún dando la contraseña correcta de juan, porque juan en la red es el 1500, y está entrando con 1234. Si logra acceder, el servidor NFS sólo le daría permiso de lectura a los ficheros grabados con uid 1234, que no existen.

Si lo permite. Basta que el usuario juan del laptop se autentique como el juan de la red. Un ejemplo: kinit juan@ORGANIZACION.ORG. Para ello el juan del laptop tiene que tener configurado su cliente kerberos con los parámetros del realm kerberos. Y todavía puedes llevar el tema más lejos: relaciones de confianza entre realms kerberos, igual que hace el AD.

Ah. ¿Entonces es kerberos quien le cambia el UID a todo lo que entra/sale de la red, todas las peticiones de ficheros y lecturas? Mmmm... no se, podría ser, pero eso tendría que probarlo.

No, no. Eso lo hace LDAP. No sé si me estoy explicando. LDAP es el que se encarga de almacenar la info de usuarios (uids y gids), direcciones de email, etc. Kerberos solo autentica. Saludos. -- 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 2009-12-22 a las 14:34 -0500, jaime velez escribió:

El 22/12/09 14:15, carlopmart escribió:

...

Carlos E. R. wrote:

...

...

...

Si lo permite. Basta que el usuario juan del laptop se autentique como el juan de la red. Un ejemplo: kinit juan@ORGANIZACION.ORG. Para ello el juan del laptop tiene que tener configurado su cliente kerberos con los parámetros del realm kerberos. Y todavía puedes llevar el tema más lejos: relaciones de confianza entre realms kerberos, igual que hace el AD.

Ah. ¿Entonces es kerberos quien le cambia el UID a todo lo que entra/sale de la red, todas las peticiones de ficheros y lecturas? Mmmm... no se, podría ser, pero eso tendría que probarlo.

No, no. Eso lo hace LDAP. No sé si me estoy explicando. LDAP es el que se encarga de almacenar la info de usuarios (uids y gids), direcciones de email, etc. Kerberos solo autentica. ya decia yo que kerberos estaba haciendo maravillas...

Kerberos es un mecanismo muy refinado para autenticar.. punto pelota... pero para hacer lo mismo con ldap - nss/pam.. suficiente.

Vamos a ver, es que entonces estamos en las mismas. Entres como entres, ldap, kerberos, nis... los ficheros que en el servidor tienen UID 1500 se exportan siempre con UID 1500, por lo que sólo el usuario que entre con UID 1500 podrá acceder, con los permisos de escritura y lectura que tengan el directorio para ese UID. Si un usuario nuevo tiene el UID 1600, no podrá leer esos ficheros, entre como entre. Podrá autentificarse en el servidor con kerberos o lo que sea, de acuerdo. Pero tiene el UID 1600... La única manera de que acceda a los ficheros del 1500 es que "algo" intercepte todas las peticiones del 1600 y diga que las hace el 1500. Y el LDAP desde luego no hace eso. Lo que hace es decir que el 1500 se llama en esta red juan y tiene tal contraseña. Y el kerberos mira esos datos en ldap, y le deja entrar o no. Nada más.

ahora me pregunto si NFS soporta ACL's y si el mecanismo de acl's sera mejor que lo que intenta carlos y de pronto si que agarramos un cañon pa aplastar moscas

Se supone que sí, lo soporta. A partir de la versión 3, dice el manual. Yo con acl no tengo experiencia, pero entonces el truco sería all_squash, y dar permisos con acl en vez de uids. Pero yo no intento nada, sólo explico lo que sé del nfs :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksxK1AACgkQtTMYHG2NR9X1egCcDvj2zBIDndU3MB2KGgONUB4K bv0An3oWGCuoa8yND0K74GH0PJnNkwm+ =gcLU -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-22 a las 21:41 +0100, carlopmart escribió:

Carlos E. R. wrote:

A todo ok, pero es que aquí perdeis de vista algo que és importantísimo. En las infraestructuras donde se realizan despliegues de este nivel (yo llevo unos 12 a mis espaldas, la mitad de los cuales los he tenido que hacer contra AD y con cluster filesystems por debajo como GFS2 y GlusterFS, para complicarlo más), el tipo de "problema" que estáis discutiendo no se dá (yo no me lo he encontrado nunca y podría aparecer pero tal vez podemos hablar de un caso de cada 100 o más) porque es tán secillo como que TODO el mundo tiene que tener user en LDAP y pass en kerberos (o en un Active Directory) o directamente no entra. Es así de sencillo. Este tipo de problemática es mas habitual en empresa pequeña y alguna mediana a lo mejor y para eso está samba (un despliegue de este tipo como dijo Jaime es matar moscas a cañonazos, a menos que hablemos de empresas con datos muy muy sensibles, aunque sean pequeñas, que las hay). Pero no en el resto, ya que los casos que planteais en principio no se pueden dar: un usuario con un laptop que no sea de la organización no va a conectarse a recursos como NFS o CIFS o SMB.

Vale, entonces confirmas lo que digo desde el principio: para nfs los usuarios han de tener el mismo uid en todos los ordenadores de la red, lo cual se hace mejor, si la red es grande, con un control de usuarios centralizado, como es ldap+kerberos. Y por otro lado, no existe un mecanismo para mapear usuarios, que es la situación que ocurre cuando quieres conectar por nfs dos ordenadores en los que lo anterior no se tuvo en cuenta al principio. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksxOi0ACgkQtTMYHG2NR9VNdgCfVSSH9k6v3y9ek63lTd58oqMl dz0Anjm3nPraW8Y+PNWPsuSSPHrJwcUq =8k/C -----END PGP SIGNATURE-----

El Tue, 22 Dec 2009 21:41:03 +0100, carlopmart escribió:

Carlos E. R. wrote:

(...)

...

La única manera de que acceda a los ficheros del 1500 es que "algo" intercepte todas las peticiones del 1600 y diga que las hace el 1500.

Y el LDAP desde luego no hace eso. Lo que hace es decir que el 1500 se llama en esta red juan y tiene tal contraseña. Y el kerberos mira esos datos en ldap, y le deja entrar o no. Nada más.

A todo ok, pero es que aquí perdeis de vista algo que és importantísimo. En las infraestructuras donde se realizan despliegues de este nivel (yo llevo unos 12 a mis espaldas, la mitad de los cuales los he tenido que hacer contra AD y con cluster filesystems por debajo como GFS2 y GlusterFS, para complicarlo más), el tipo de "problema" que estáis discutiendo no se dá (yo no me lo he encontrado nunca y podría aparecer pero tal vez podemos hablar de un caso de cada 100 o más) porque es tán secillo como que TODO el mundo tiene que tener user en LDAP y pass en kerberos (o en un Active Directory) o directamente no entra. Es así de sencillo. Este tipo de problemática es mas habitual en empresa pequeña y alguna mediana a lo mejor y para eso está samba (un despliegue de este tipo como dijo Jaime es matar moscas a cañonazos, a menos que hablemos de empresas con datos muy muy sensibles, aunque sean pequeñas, que las hay). Pero no en el resto, ya que los casos que planteais en principio no se pueden dar: un usuario con un laptop que no sea de la organización no va a conectarse a recursos como NFS o CIFS o SMB.

No es eso. El tamaño de una empresa es indiferente. Yo puedo tener 5 usuarios pero dependiendo del tipo de sector en el que me encuentre (agencia gubernamental, por ejemplo) me pueden exigir el uso de una tecnología u otra. O puedo tener 250 usuarios y necesitar samba/cifs para compartir las impresoras en entornos mixtos. Si necesito seguridad, puedo aplicar igualmente el uso de kerberos y de ldap como servidor de directorios. Es decir, visto desde fuera, con samba obtienes lo mejor de los dos mundos: la flexibilidad de una configuración potente (sin necesidad de recurrir a elementos externos) y la seguridad de kerberos junto con el uso de directorios activos. Y mira que samba me da tirria :-) A lo que voy es a las *capacidades intrínsecas* de cada sistema: - Samba parece más flexible en cuanto a que permite mayor control sobre los accesos y los permisos de los recursos (y no necesitas implementar kerberos ni ldap para gestionarlo). - En cambio NFS parece más simplón y limitado, y necesitas utilizar recursos externos (kerberos y ldap) para darle cierta flexibilidad en cuanto a qué usuarios pueden acceder a qué recursos y tener mayor control y seguridad. Y tener que implementar kerberos y ldap no siempre es factible ni deseable (porque te puede traer más problemas de los que te soluciona). Luego... ¿cuál es la ventaja "efectiva" (real) de NFS sobre samba/cifs? ¿Rendimiento? :-?

...

...

ahora me pregunto si NFS soporta ACL's y si el mecanismo de acl's sera mejor que lo que intenta carlos y de pronto si que agarramos un cañon pa aplastar moscas

Se supone que sí, lo soporta. A partir de la versión 3, dice el manual.

Yo con acl no tengo experiencia, pero entonces el truco sería all_squash, y dar permisos con acl en vez de uids.

Pero yo no intento nada, sólo explico lo que sé del nfs :-)

NFS implanta acls bastante potentes, pero recomiendo leer la doc.

*** man nfs acl / noacl Selects whether to use the NFSACL sideband protocol on this mount point. The NFSACL sideband protocol is a proprietary protocol implemented in Solaris that manages Access Control Lists. NFSACL was never made a standard part of the NFS protocol specification. If neither acl nor noacl option is specified, the NFS client negotiates with the server to see if the NFSACL protocol is supported, and uses it if the server supports it. Disabling the NFSACL sideband protocol may be necessary if the negotiation causes problems on the client or server. Refer to the SECURITY CONSIDERATIONS section for more details. ... NFS Access Control Lists Solaris allows NFS version 3 clients direct access to POSIX Access Control Lists stored in its local file systems. This proprietary sideband protocol,known as NFSACL, provides richer access control than mode bits. Linux implements this protocol for compatibility with the Solaris NFS implementation. The NFSACL protocol never became a standard part of the NFS version 3 specification, however. The NFS version 4 specification mandates a new version of Access Control Lists that are semantically richer than POSIX ACLs. NFS version 4 ACLs are not fully compatible with POSIX ACLs; as such, some translation between the two is required in an environment that mixes POSIX ACLs and NFS version 4. *** Ya empezamos con las incompatilidades... ¡NFS parece más "protocolario" que samba! :-P Saludos, -- Camaleón -- 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 2009-12-22 a las 21:56 -0000, Camaleón escribió: ...

A lo que voy es a las *capacidades intrínsecas* de cada sistema:

- Samba parece más flexible en cuanto a que permite mayor control sobre los accesos y los permisos de los recursos (y no necesitas implementar kerberos ni ldap para gestionarlo).

- En cambio NFS parece más simplón y limitado, y necesitas utilizar recursos externos (kerberos y ldap) para darle cierta flexibilidad en cuanto a qué usuarios pueden acceder a qué recursos y tener mayor control y seguridad.

Y tener que implementar kerberos y ldap no siempre es factible ni deseable (porque te puede traer más problemas de los que te soluciona).

Luego... ¿cuál es la ventaja "efectiva" (real) de NFS sobre samba/cifs? ¿Rendimiento? :-?

Creo que sí, rinde más. Bueno, con mi ethernet normalita la pongo a tope, no da más. Es también muy simple de configurar (olvidate de kerberos y eso), porque los permisos y accesos son los del linux, tal cual. Ahora mismo yo estoy compartiendo mi "home", de manera que en el ordenador nuevo puedo acceder al correo del antiguo mediante thunderbird. Obviamente, tuve la precaución de asegurarme que los dos usuarios tuvieran el mismo uid. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksxdGQACgkQtTMYHG2NR9VfJgCZAV6+IIz5xtqbNuZfe38VELbE gnwAni4nrLaCa4b3stKwPoA/lFu+dIdZ =MpNn -----END PGP SIGNATURE-----

Camaleón wrote:

El Mon, 21 Dec 2009 22:16:06 +0100, carlopmart escribió:

...

Bueno no sé que tipo de red o que usos quieres dar a la topología de conexiones nfs, pero si estás con nfsv4, que creo que sí, lo que quieres hacer precisarás de la utilización de kerberos en nfs junto con ldap para el tema del mapeo de usuarios y permisos y así evitarte problemas de que un usuario que se loguee desde una estación u otra pueda escribir o leer o todo lo contrario.

Pregunta tonta: ¿por qué NFS no implementa los permisos heredados del sistema anfitrión en que se ejecuta?

Lo que estáis comentando sobre el funcionamiento del NFS, una de dos, o no lo he entendido bien o me parece un tanto inseguro y tener que recurrir a kerberos+ldap me parece desorbitado para el propósito.

Hasta samba usa el mapeo de usuario (usuario windows<=>usuario samba<=> usuario linux) sin necesidad de recurrir a kerberos :-?

Saludos,

En NFS también, los permisos son heredados en el caso de que no uses la combinación kerberos+ldap. Solo que la versión NFSv4 puede funcionar de una forma u otra. Si a NFSv4 lo quieres hacer funcionar al estilo samba, harias exactamente lo mismo, mapear todo hacia un usuario con permisos en el directorio exportado. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Antes que nada gracias por tantas respuestas! Les comento lo que he logrado... En el lugar donde me encuentro yo somos principalmente 4 usuarios, entonces lo que he hecho es configurarle a cada uno de los usuarios el mismo UID en todas las PCs. Esto que en un principio me parecía raro en realidad no creo que lo sea tanto. Quizás esto le aclare algo las dudas a Camaleón con respecto a los IDs de los usuarios, no sé si es a esto lo que te referías pero te comento lo que voy aprendiendo... Se supone que el que da de alta a un usuario nuevo (en realidad no se supone, es así) es el usuario root, el cual debe saber bien lo que hace (esto si que no se dá en todos los casos :P). Por lo que configurar el mismo usuario en distintas PCs con un mismo UID no es algo raro como creia en un principio y además con esto podemos tener el usuario "mauro" con UID 1000 en una PC y el usuario "maurito" (que es físicamente la misma persona, osea Mauro, pero que por una de esas raras cuestiones de la vida usa distinto nombre de usuario en distintas PCs) también con el UID 1000 y que al entrar a la carpeta montada mediante NFS sea tratado como "mauro". Esto acá me resultó realmente cómodo ya que como el server lo armé yo le puse nombres de usuario más coherentes (a mi gusto) que los que tienen mis compañeros en sus PCs. Por otro lado imaginando que uno sepa o al menos estime el UID de un usuario con acceso a las carpetas montadas con NFS tendría que crear un usuario cualquiera con ese UID y acceder desde una PC que esté habilitada para hacerlo (de momento uso la IP para autorizar o no el acceso), por lo cual no es nada fácil que lo logre, ya que se tendría que loguear como root en una de estas PCs. Ahora bien, sigo con las preguntas si ustedes me lo permiten (y reitero las gracias). Veo que acá hablan mucho de Kerberos, LDAP y NFSv4. Me podrían explicar muy pero muy básicamente que es cada cosa y para que sirve específicamente así luego me dedico a leer sobre el tema y ver que otra modificación hago a mi servidor??? De momento tengo hecho / configurado lo siguiente: - La carpeta /home del servidor está compartida mediante NFS. En esta carpeta cada uno de nosotros tiene un directorio home con acceso de escritura para poder guardar sus cosas personales. - La manera de autorizar quienes pueden montar esa carpeta está definida en /etc/exports y es mediante la IP de la PC, es decir: /carpeta a compartir xxx.xxx.xxx.xxx()opcion1,opcion2,opcion3) Qué más les parece a ustedes que haga falta (se que soy yo el que lo tiene que hacer, pero se aceptan sugerencias, quizás haya algo básico que no esté teniendo en cuenta). Les preguntaba sobre LDAP y Kerberos porque quiero ver que tan necesario me resultaría darle más seguridad al servidor. Olvidé mencionar (creo que esto es muy importante) que el mismo va a tener una IP pública accesible obviamente desde cualquier lugar del mundo... Bueno, perdón por mis tan extensos mails, es que quiero ser lo más claro posible. Gracias por todo y hasta luego! Mauro. Camaleón escribió:

...

Pero en samba, si el usuario no existe (no está creado ni está mapeado, ni dado de alta en la bd de samba), no tiene acceso al recurso, se le trataría como "invitado" (con un UID distinto, entiendo, el de "nobody") y por tanto, sin permisos (dependiendo de la configuración del recurso).

Pero por lo que comenta Mauro (si no he entendido mal), en NFS ¿sí tendría acceso porque se mapea "indistintamente" con el mismo UID a todos...?

Es que suena un tanto raro ese comportamiento del NFS de que si el usuario no existe, se le "auto-asigne" un UID de un usuario existente >:-?

Saludos,

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

carlopmart escribió:

Camaleón wrote:

...

El Tue, 22 Dec 2009 18:02:56 +0100, carlopmart escribió:

...

Camaleón wrote:

...

...

Pregunta tonta: ¿por qué NFS no implementa los permisos heredados del sistema anfitrión en que se ejecuta?

(...)

...

Si a NFSv4 lo quieres hacer funcionar al estilo samba, harias exactamente lo mismo, mapear todo hacia un usuario con permisos en el directorio exportado.

Pero en samba, si el usuario no existe (no está creado ni está mapeado, ni dado de alta en la bd de samba), no tiene acceso al recurso, se le trataría como "invitado" (con un UID distinto, entiendo, el de "nobody") y por tanto, sin permisos (dependiendo de la configuración del recurso). Pero por lo que comenta Mauro (si no he entendido mal), en NFS ¿sí tendría acceso porque se mapea "indistintamente" con el mismo UID a todos...?

Es que suena un tanto raro ese comportamiento del NFS de que si el usuario no existe, se le "auto-asigne" un UID de un usuario existente

...

:-?

Saludos,

Eso ocurre porque en el archivo exports le estás diciendo que lo haga y estás dando acceso por IP, sin user ni pass ... ¿ves la diferencia?

Y cómo se puede hacer para poner acceso por contraseña??? Eso sería muy útil, ya que si no cualquier usuario que se conecte desde una IP "autorizada" para hacerlo podrá usmear en los archivos de los demás, aunque claro está no tendrá permisos de escritura. Saludos. -- 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

Carlos E. R. escribió:

El 2009-12-22 a las 15:02 -0200, Mauro Antivero escribió:

...

...

Eso ocurre porque en el archivo exports le estás diciendo que lo haga y estás dando acceso por IP, sin user ni pass ... ¿ves la diferencia?

Y cómo se puede hacer para poner acceso por contraseña??? Eso sería muy útil, ya que si no cualquier usuario que se conecte desde una IP "autorizada" para hacerlo podrá usmear en los archivos de los demás, aunque claro está no tendrá permisos de escritura.

Y si es el administrador del ordenador cliente, y quiere acceder al home de otro usuario (de otro ordenador), no tiene más que crear un usuario en su ordenador con el UID del directorio exportado que quiere ver/tocar, y listo, accede.

-- Saludos Carlos E. R.

Eso es un gran problema no? Ya que si yo quiero acceder a la carpeta de otro en el servidor tal y como vos decís me hago en mi PC una cuenta con el UID que tiene el usuario al cual le quiero acceder a la carpeta y listo? Suponiendo un entorno en el que no sea fácil acceder al a PC del compañero, es fácil determinar su UID para hacer este tipo de cosas?? Acá eso no va a pasar ya que somos un grupo reducido y tenemos confianza, pero siempre es bueno saber más para preparase por su el día de mañana es necesario hacer algo más seguro. Saludos. -- 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

Mauro Antivero wrote:

carlopmart escribió:

...

Camaleón wrote:

...

El Tue, 22 Dec 2009 18:02:56 +0100, carlopmart escribió:

...

Camaleón wrote:

...

Pregunta tonta: ¿por qué NFS no implementa los permisos heredados del sistema anfitrión en que se ejecuta? (...)

...

Si a NFSv4 lo quieres hacer funcionar al estilo samba, harias exactamente lo mismo, mapear todo hacia un usuario con permisos en el directorio exportado. Pero en samba, si el usuario no existe (no está creado ni está mapeado, ni dado de alta en la bd de samba), no tiene acceso al recurso, se le trataría como "invitado" (con un UID distinto, entiendo, el de "nobody") y por tanto, sin permisos (dependiendo de la configuración del recurso). Pero por lo que comenta Mauro (si no he entendido mal), en NFS ¿sí tendría acceso porque se mapea "indistintamente" con el mismo UID a todos...?

Es que suena un tanto raro ese comportamiento del NFS de que si el usuario no existe, se le "auto-asigne" un UID de un usuario existente

...

:-? Saludos,

Eso ocurre porque en el archivo exports le estás diciendo que lo haga y estás dando acceso por IP, sin user ni pass ... ¿ves la diferencia?

Y cómo se puede hacer para poner acceso por contraseña??? Eso sería muy útil, ya que si no cualquier usuario que se conecte desde una IP "autorizada" para hacerlo podrá usmear en los archivos de los demás, aunque claro está no tendrá permisos de escritura.

Saludos.

Con kerberos. Dos enlaces: http://blogs.netapp.com/eislers_nfs_blog/ http://www.nfsv4.org/ -- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Camaleón wrote:

El Tue, 22 Dec 2009 18:51:11 +0100, carlopmart escribió:

...

Camaleón wrote:

...

...

...

Si a NFSv4 lo quieres hacer funcionar al estilo samba, harias exactamente lo mismo, mapear todo hacia un usuario con permisos en el directorio exportado. Pero en samba, si el usuario no existe (no está creado ni está mapeado, ni dado de alta en la bd de samba), no tiene acceso al recurso, se le trataría como "invitado" (con un UID distinto, entiendo, el de "nobody") y por tanto, sin permisos (dependiendo de la configuración del recurso).

Pero por lo que comenta Mauro (si no he entendido mal), en NFS ¿sí tendría acceso porque se mapea "indistintamente" con el mismo UID a todos...?

Es que suena un tanto raro ese comportamiento del NFS de que si el usuario no existe, se le "auto-asigne" un UID de un usuario existente

...

:-? Eso ocurre porque en el archivo exports le estás diciendo que lo haga y estás dando acceso por IP, sin user ni pass ... ¿ves la diferencia?

Errr... nop O:-)

Si el usuario no existe en el anfitrión, no debería tener acceso a ese recurso, eso es lo que no acabo de pillar... es decir, que un usuario inexistente debería tener los mismos permisos que el usuario "nobody" (en todo caso) pero no los mismos permisos que el resto de usuarios del sistema.

Eso dependerá del administrador como haya configurado. Si ha puesto que sea root, pues tendrá los accesos a los que los archivos den permiso. Si ha configurado nobody, tendrá acceso solo a directorios y archivos con permisos en el grupo de "other"

Y lo más importante ¿al final es necesario usar kerberos con NFS4 o es un paso opcional? :-?

Es opcional. No es un requisito sine qua non ...

Saludos,

-- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Carlos E. R. wrote:

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

El 2009-12-22 a las 17:16 -0000, Camaleón escribió:

...

Pero en samba, si el usuario no existe (no está creado ni está mapeado, ni dado de alta en la bd de samba), no tiene acceso al recurso, se le trataría como "invitado" (con un UID distinto, entiendo, el de "nobody") y por tanto, sin permisos (dependiendo de la configuración del recurso).

Pero por lo que comenta Mauro (si no he entendido mal), en NFS ¿sí tendría acceso porque se mapea "indistintamente" con el mismo UID a todos...?

Es que suena un tanto raro ese comportamiento del NFS de que si el usuario no existe, se le "auto-asigne" un UID de un usuario existente

...

:-?

No se autoasigna.

O entra cada usuario a su UID, o dices que el recurso es anónimo (squashed), y todos entran como anónimos (lo sean o no).

root_squash Hace que el usuario root del cliente acceda como usuario "squashed" del servidor, no como root.

no_root_squash Lo contrario, el root cliente entra al servidor como root.

all_squash Todos los usuarios entran con el uid:gid anónimo.

anonuid anongid Cambia el UID:GID del usuario anónimco.

Eso son las combinaciones que hay, no más. Es menos potente que el samba en este aspecto.

No, no lo és. Es igual de potente. Solo que para disponer de esa potencia debes utilizar kerberos y LDAP o un AD en su defecto.

Lo que sí puedes hacer, creo, es exportar diferentes directorios con diferentes usuarios anónimos, un directorio por linea en el exports. No lo he probado ni comprobado, es una idea que se me acaba de ocurrir.

- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksxDSUACgkQtTMYHG2NR9UgqwCfUMrl9LkOvxPw1pOa5p5YO+8b 7VcAoJXedwjEERn3l9JrPJ4V8bLNaQd8 =rluc -----END PGP SIGNATURE-----

-- CL Martinez carlopmart {at} gmail {d0t} com -- 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

Carlos E. R. wrote:

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

El 2009-12-22 a las 19:52 +0100, carlopmart escribió:

...

Carlos E. R. wrote:

...

...

root_squash Hace que el usuario root del cliente acceda como usuario "squashed" del servidor, no como root.

no_root_squash Lo contrario, el root cliente entra al servidor como root.

all_squash Todos los usuarios entran con el uid:gid anónimo.

anonuid anongid Cambia el UID:GID del usuario anónimco.

Eso son las combinaciones que hay, no más. Es menos potente que el samba en este aspecto.

No, no lo és. Es igual de potente. Solo que para disponer de esa potencia debes utilizar kerberos y LDAP o un AD en su defecto.

Creo que te equivocas. No veo en el manual del nfs nada para mapear uids.

¿A que te refieres con mapeo de uids? ¿O te estás refiriendo al cambio del propietario de archivo como hace samba?? Por ejemplo: un directorio propietario del usuario pepe1 y permites el acceso a los usuario pepe2, pepe3 y pepe4 con acceso de escritura. Si se producen cambios en los archivos, estos quedan registrados como pepe1. ¿Es eso? Si es esto, no se trata de mapeo de uids, si no de cambios de propietarios ... Saludos.

- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksxF5cACgkQtTMYHG2NR9WmnwCfZ0dxO1rhk4XJdSZEB5hoJJsI m6YAniQAWLAhBbiJ5Czkedgonv8Sfl1g =mBgF -----END PGP SIGNATURE-----

-- CL Martinez carlopmart {at} gmail {d0t} com -- 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 2009-12-22 a las 20:13 +0100, carlopmart escribió:

carlopmart wrote:

...

Carlos E. R. wrote:

...

...

Creo que te equivocas. No veo en el manual del nfs nada para mapear uids.

¿A que te refieres con mapeo de uids? ¿O te estás refiriendo al cambio del propietario de archivo como hace samba?? Por ejemplo: un directorio propietario del usuario pepe1 y permites el acceso a los usuario pepe2, pepe3 y pepe4 con acceso de escritura. Si se producen cambios en los archivos, estos quedan registrados como pepe1. ¿Es eso? Si es esto, no se trata de mapeo de uids, si no de cambios de propietarios ...

Saludos.

Vale espera, creo que sí te refieres al caso que he expuesto, ¿verdad?. Lo digo porque en arquitecturas de autenticación distribuida el concepto cambia, pero para entendernos todos lo dejamos tal que así.

Se trata de que el NFS controla el acceso a cada directorio y fichero según los permisos de usuario, grupo,resto, comparando el UID:GID del usuario solicitante con los de el fichero y directorio al que quiere acceder. Así, si un fichero exportado es: - -rwxr----- 1 1000 100 26 2009-04-24 22:46 p* UID GID el usuario que entre al servidor con UID 1000 tendrá acceso de lectura y escritura, y el usuario que entre con UID 1001 y GID 100 tendrá sólo acceso de lectura. Ahora bien, si ese mismo usuario (mismo nombre) se conecta desde otro ordenador en el que tenga el UID 2000:200, no tendrá ningún tipo de acceso a ese fichero, independientemente de que haya sido listado por LDAP y autorizado por kerberos. El mecanismo para que pudiera acceder es que "algo" mapeara el usuario externo 2000:200 al interno 1000:100. Y que yo sepa eso no existe. A ver si consigo explicarme con este mensaje :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksxK2UACgkQtTMYHG2NR9WkEgCfWaJquMPrjl1UfPQmIHeFPiQu IXUAmwQ7yxm7JaKdWuqabrDhWxu/+H8W =hqtZ -----END PGP SIGNATURE-----

Hola :) On Tuesday 22 December 2009 17:28:56 Camaleón wrote:

El Mon, 21 Dec 2009 22:16:06 +0100, carlopmart escribió:

...

Bueno no sé que tipo de red o que usos quieres dar a la topología de conexiones nfs, pero si estás con nfsv4, que creo que sí, lo que quieres hacer precisarás de la utilización de kerberos en nfs junto con ldap para el tema del mapeo de usuarios y permisos y así evitarte problemas de que un usuario que se loguee desde una estación u otra pueda escribir o leer o todo lo contrario.

Pregunta tonta: ¿por qué NFS no implementa los permisos heredados del sistema anfitrión en que se ejecuta?

Lo que estáis comentando sobre el funcionamiento del NFS, una de dos, o no lo he entendido bien o me parece un tanto inseguro y tener que recurrir a kerberos+ldap me parece desorbitado para el propósito.

Hasta samba usa el mapeo de usuario (usuario windows<=>usuario samba<=> usuario linux) sin necesidad de recurrir a kerberos :-?

Por una razón histórica. Cuando salió en NFS, se usaba NIS o, mejor dicho, YP (Yellow Pages), pero tuvieron que cambiar el nombre por temas legales y se quedó en NIS. Luego aparecieron los LDAPs y los ADs y esas cosas que "hacen lo mismo" que el NIS. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- 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

Mauro Antivero wrote:

...

Sobre el fsid=0, es un pseudofilesystem específico para nfs4, que precisarás utilizar junto con "insecure".

Perdón, pero ahora entiendo menos eso del fsid... No podrías decirlo en castellano básico para niños de jardín? :P Tené en cuenta que hace dos días que empecé con esto.

Saludos y gracias!

Mauro.

...

Saludos.

El fsid en NFSv4 tiene un sentido especial. Cuando os encontrais una entrada del tipo fsid=0 en un exports se está refiriendo a que ES el root filesystem de todos los exports, es el root filesystem del resto de directorios a exportar. Parecido a lo que es el root filesystem de un Unix, pero que no tiene nada que ver con los dispositivos que podeis encontrar bajo /dev Tambien os lo podeis encontrar configurado algo tal que así: fsid=567, por ejemplo. En este caso dependerá de donde esté corriendo el servidor nfsv4. Por ejemplo, el fsid con un valor distinto a 0 se utiliza en clusters de servidores para diferenciar un export de otro entre todos los nodos que componen el cluster y así cuando el proceso nfs caiga en un nodo y se levante en otro por ejemplo, se esté exportando todo igual que en el nodo original. También es asignado cuando varios servidores sin pertenecer a un cluster nfsv4 están exportando el mismo filesystem utilizando filesystems de cluster como OCFS2, GFS2, GlusterFS, etc. Y por último. Puedes usar fsid distinto a 0 también, para que cuando por ejemplo se te estropee un disco duro y lo reeemplaces y te cambie el nombre del dispositivo, por ejemplo de sdb a sdd, el filesystem se siga exportando sin problemas y de forma congruente con el original. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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