Re: Servidor FTP (vsftpd) y enlaces simbólicos
El Mon, 02 Jun 2014 19:48:45 +0200, José Miguel (sio2) escribió:
> El Mon, 02 de Jun de 2014, a las 02:23:43PM +0000, Camaleón dijo:
>
>> Si el problema no era de jaulas, el montaje con "bind" no te va a
>> servir, por eso me extrañaba que dieras esa opción como válida.
>
> El problema es provocado por la jaula, lo que pasa que no es el típico
> problema de que los contenidos queden fuera de la jaula, sino que la
> jaula modifica el directorio raíz y como consecuencia la ruta absoluta
> deja de ser válida dentro de la jaula. Creo que en todo este hilo es eso
> lo que no he sido capaz de transmitir bien o tú no has comprendido del
> todo.
Pero la jaula (y el montaje con --bind) lo único que hace es permitir que
un usuario sin acceso a un directorio (por quedar fuera de su ámbito)
pueda acceder. No debería interferir para nada en el comportamiento del
ftp ni de los enlaces simbólicos, siempre y cuando estén configurados los
permisos correctamente.
> Veamos. El fichero:
>
> /srv/ftp/Almacen/Contenedor/f.txt
>
> tiene una ruta absoluta que es esa precisamente:
>
> /srv/ftp/Almacen/Contenedor/f.txt. Si en el sistema tengo un enlace
> simbólico con esa ruta absoluta, el enlace no está roto. Ahora bien, el
> servidor FTP no tiene como raiz la raíz del sistema, sino
> /srv/ftp/Material, porque está enjaulado en ese directorio. Así pues a
> ojos del FTP la ruta absoluta de ese fichero f.txt /Contenedor/f.txt,
> puesto que /srv/ftp/Almacen/Contenedor/f.txt referiría al un hipotético
> fichero que en el sistema de archivos se encontrase en:
>
> /srv/ftp/Almacen/srv/ftp/Almacen/Contenedor/f.txt
>
> Eso es lo que le pasa a mis enlaces simbólicos con ruta absoluta: son
> válidos en el sistema, pero en el FTP, no.
Eso está claro pero no es ese tu problema ¿no? porque si lo es volvemos
al principio del hilo.
El usuario que accede mediante ftp tiene que tener acceso a "/srv/ftp/
Almacen" y todo lo que cuelgue de ahí, para eso sirve precisamente montar
el recurso "bindeado". Si no tiene acceso, ningún enlace (sea duro o
blando) funcionará.
> ¿Qué tiene de malo esto? Pues que el comportamiento del FTP cuando se
> sube un fichero no es sobreescribir el enlace simbólico por el fichero
> regular que estoy subiendo (a diferencia de mv o cp que sí lo hacen),
> sino seguir el enlace y modificar el fichero apuntado (f.txt en este
> ejemplo). Si el enlace está roto, el FTP no encuentra el fichero
> apuntado y suelta un error.
Pues entonces si esa es tu teoría, si crees que el servidor ftp es capaz
de reconocer los enlaces simbólicos y seguirlos pero se topa con el muro
de la jaula que le impide acceder al recurso tienes que solucionar eso,
obviamente. Pero como estabas tan convencido de que este no era un
problema de enjaulamiento me has hecho dudar :-)
Salvo que lo que quieras (como así parece ser) es sobrescribir el enlace
simbólico por un archivo con el contenido completo que subes, vamos, que
quieras romper ese enlace simbólico para generar un archivo convencional.
> Creo que por el RFC que me indicaste, aunque no lo entiendo muy bien,
> este es el comportamiento lógico del protocolo: no hay dos ficheros (el
> enlace simbólico y el fichero regular), sino un solo fichero al que se
> puede llegar por dos rutas diferentes; y, por tanto, no sería posible
> hacer lo que me hubiera gustado: que el FTP en las subidas se comportase
> como los comandos mv o cp.
"cp -H" tendría el comportamiento que tiene el ftp cuando subes un
archivo, y que entiendo tiene prioridad en este caso.
Vale, entonces ya veo que el problema no es de la jaula ni de permisos ni
de rutas relativas/absolutas ni demás gaitas, lo que quieres es que el
servidor ftp rompa en enlace simbólico sin generar ningún error. Lo cual
me lleva a la siguiente preguntonta... si no quieres que se sigan los
enlaces simbólicos ¿para qué los generas?
(...)
>> Lo que me queda claro es que sabemos en qué condiciones (cuándo) falla
>> (cuando ya existe un archivo con ese nombre que es un enlace simbólico)
>> pero no porqué, intenta que el servidor ftp saque más información.
>
> Yo sí veo claro por qué: porque el enlace a ojos de FTP está roto y
> apunta a un fichero que no existe dentro de un directorio que no existe.
(...)
Bien, en tu caso no existe porque no lo has configurado para que tenga
acceso pero sería posibles hacerlo, aunque si al final he entendido lo
que quieres hacer, no es eso lo que buscas.
>> Dos pruebas adicionales que se me ocurren:
>> 1/ Probar con un enlace duro
>
> Eso va a funcionar: no veo el problema de que no lo haga.
>
>> 2/ Probar con ssh (mediante sftp)
>
> Tengo la duda. Creo que alguien me dijo que le funcionaba. Quizás porque
> el sftp de ssh, sí sobreescribe el enlace simbólico en vez de seguir su
> ruta.
Curioso, aunque bueno, ftp es un protocolo muy antiguo y básico, tampoco
se le puede pedir mucho.
>> 3/ Probar con un enlace simbólico que esté en el mismo directorio
>
> No entiendo esto que dices.
Para descartar problemas con la jaula pero ya has confirmado que los
usuarios no tienen acceso al directorio "/srv/ftp/Almacen/".
>> Yo entendería que lo más sencillo (lo más lógico) es que sobrescribiera
>> el destino al que apunta el enlace simbólico siempre y cuando tenga los
>> permisos adecuados y que en este caso los tiene (aparentemente).
>
> Es que eso es lo que hace: el problema es el que te he apuntado al
> principio: que el cambio de raíz rompe las rutas absolutas.
Ya veo, pero aunque no hubiera cambio de raíz y el enlace se pudiera
seguir, al subir el archivo (put) se modificaría el destino y veo que no
es eso lo que quieres porque eso sí que sería factible configurando la
jaula correctamente.
Saludos,
--
Camaleón
Reply to: