Servidor FTP (vsftpd) y enlaces simbólicos

[José Miguel (sio2)]

Hola, listeros:

Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.

Mi problema es el siguiente:

Tengo un servidor FTP enjaulado al que se suben de vez en cuando
archivos. Estos archivos semanalmente son movidos por un script a un
almacen y en su lugar se deja un enlace simbólico con ruta absoluta.
Como el servidor FTP está enjaulado, la raíz del sistema no coincide
con la suya, por lo que a ojos del servidor FTP el enlace simbólico
no enlaza con un archivo existente. Como los ficheros se descargan por
web, no hay ningún problema en las descargas.

El problema surge cuando se quiere actualizar un fichero existente. He
comprobado que el servidor FTP no se comporta como los comandos cp o mv
de linux. Con estos comandos, si se sobreescribe un enlace simbólico con
un fichero regular, desaparece el enlace simbólico y su lugar lo ocupa
el nuevo fichero. En cambio, cuando se sobreescribe un fichero, el FTP
no hace esto, lo que hace es seguir la ruta del enlace simbólico y
sustituir el fichero apuntado. Y ese es el problema: como el fichero
apuntado "no existe", se produce un error y la subida del fichero falla.
Si primero se borra el fichero del servidor (enlace simbólico) y luego
se sube la nueva versión del fichero, no hay problema.

He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer que
al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez de
seguir la ruta y cambiar el fichero enlazado?

[1] Alguno podrá argumentar que puedo usar rutas relativas en los
enlaces. El problema de eso es que entonces si un usuario decide
reorganizar un poco los ficheros del servidor, creando subdirectorios y
metiendo dentro de él ficheros, los enlaces simbólicos se romperán.

Gracias de antemano.
--
Parezco en mi fortuna al Manzanares,
que con agua o sin ella siempre es río.
--- Tomé de Burguillos ---

[Camaleón]

Post by José Miguel (sio2)
Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.

Hum... "excusatio non petita..." :-)

Post by José Miguel (sio2)
Tengo un servidor FTP enjaulado al que se suben de vez en cuando
archivos. Estos archivos semanalmente son movidos por un script a un
almacen y en su lugar se deja un enlace simbólico con ruta absoluta.
Como el servidor FTP está enjaulado, la raíz del sistema no coincide con
la suya, por lo que a ojos del servidor FTP el enlace simbólico no
enlaza con un archivo existente. Como los ficheros se descargan por web,
no hay ningún problema en las descargas.

Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
punteros a rutas que están fuera del alcance del servidor ftp? Se te
lleva más espacio en disco pero puedes verlo como una copia de seguridad.

Post by José Miguel (sio2)
El problema surge cuando se quiere actualizar un fichero existente. He
comprobado que el servidor FTP no se comporta como los comandos cp o mv
de linux. Con estos comandos, si se sobreescribe un enlace simbólico con
un fichero regular, desaparece el enlace simbólico y su lugar lo ocupa
el nuevo fichero. En cambio, cuando se sobreescribe un fichero, el FTP
no hace esto, lo que hace es seguir la ruta del enlace simbólico y
sustituir el fichero apuntado. Y ese es el problema: como el fichero
apuntado "no existe", se produce un error y la subida del fichero falla.
Si primero se borra el fichero del servidor (enlace simbólico) y luego
se sube la nueva versión del fichero, no hay problema.

Tal y como lo interpreto, no es que no exista el archivo, es que el
servidor ftp no tiene acceso por estar enjaulado.

Post by José Miguel (sio2)
He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
de seguir la ruta y cambiar el fichero enlazado?

(...)

Usando enlaces duros o permitiendo el flujo convencional de acceso a los
enlaces simbólicos a través de montajes con "--bind".

Saludos,

[José Miguel (sio2)]

Post by Camaleón

Post by José Miguel (sio2)
Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.

Hum... "excusatio non petita..." :-)

Bueno, porsiaca... La verdad es que al intentar averiguar esto, me
saltaba siempre la misma explicación del mount -o bind, etc...

Post by Camaleón
Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
punteros a rutas que están fuera del alcance del servidor ftp? Se te
lleva más espacio en disco pero puedes verlo como una copia de seguridad.

También se me ocurrió eso (porque el almacen está en el mismo sistema de
ficheros), pero no me convence del todo porque dificulta la limpieza. A
veces alguno se dedica a meter ahí imágenes de máquinas virtuales, o
hasta software pirata (aunque esté terminantemente prohibido). Cuando
toca limpieza, si se usan enlaces simbólicos sé que me basta con
brujulear en el "Almacen", si se usan enlaces duros, no.

Post by Camaleón
Tal y como lo interpreto, no es que no exista el archivo, es que el
servidor ftp no tiene acceso por estar enjaulado.

No, también se tiene acceso al fichero enlazado, el problema como he
dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
situación muy simple:

/srv/ftp/Almacen/fichero.txt
/srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt

Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
/srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
que funcionaría dentro del ftp (aunque no en el sistema).

Post by Camaleón

Post by José Miguel (sio2)
He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
de seguir la ruta y cambiar el fichero enlazado?

Usando enlaces duros o permitiendo el flujo convencional de acceso a los
enlaces simbólicos a través de montajes con "--bind".

Lo primero ya te he dicho por qué no me convence. Lo segundo no
funciona, y la tercera solución (enlaces con ruta relativa) también
tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
con la forma; quizás, porque, simplemente, no se puede.

Gracias.
--
e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
--- Ludovico Ariosto ---

[Camaleón]

(...)

Post by José Miguel (sio2)

Post by Camaleón
Tal y como lo interpreto, no es que no exista el archivo, es que el
servidor ftp no tiene acceso por estar enjaulado.

No, también se tiene acceso al fichero enlazado, el problema como he
dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
/srv/ftp/Almacen/fichero.txt
/srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt
Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
/srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
que funcionaría dentro del ftp (aunque no en el sistema).

Aum... entonces no es como pensaba. Según el ejemplo simplificado que
pones, entiendo que los enlaces simbólicos están dentro de la jaula y por
tanto, accesibles de cara al servidor ftp. Pero dices que vsftpd no puede
acceder a "/srv/ftp/Curso2013-2014/fichero.txt", que da error...
¿correcto? Si es así, interesaría saber:

1/ El error que te registra el servidor ftp cuando se intenta acceder al
recurso que apunta al enlace simbólico

2/ El error que te aparece en el cliente

3/ El tipo de cliente que usas para acceder a ese recurso (aplicación
dedicada ftp, navegador web...)

(...)

Post by José Miguel (sio2)

Post by Camaleón
Usando enlaces duros o permitiendo el flujo convencional de acceso a
los enlaces simbólicos a través de montajes con "--bind".

Lo primero ya te he dicho por qué no me convence. Lo segundo no
funciona, y la tercera solución (enlaces con ruta relativa) también
tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
con la forma; quizás, porque, simplemente, no se puede.

Tendría que revisar con detenimiento el RFC del protocolo FTP (más
concretamente el #3659¹) pero en principio, que el servidor ftp no siga
los enlaces simbólicos que están dentro de su ámbito no me parece
"normal" salvo que el sistema de archivos (es decir, los permisos de
usuarios en esos directorios) lo impida.

¹http://tools.ietf.org/html/rfc3659

Saludos,

[Francesc Guitart]

Hola,

No estoy seguro de haverlo entendido bien y además me parece que mi

Post by José Miguel (sio2)

Post by Camaleón

Post by José Miguel (sio2)
Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.

Hum... "excusatio non petita..." :-)

Bueno, porsiaca... La verdad es que al intentar averiguar esto, me
saltaba siempre la misma explicación del mount -o bind, etc...

Post by Camaleón
Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
punteros a rutas que están fuera del alcance del servidor ftp? Se te
lleva más espacio en disco pero puedes verlo como una copia de seguridad.

También se me ocurrió eso (porque el almacen está en el mismo sistema de
ficheros), pero no me convence del todo porque dificulta la limpieza. A
veces alguno se dedica a meter ahí imágenes de máquinas virtuales, o
hasta software pirata (aunque esté terminantemente prohibido). Cuando
toca limpieza, si se usan enlaces simbólicos sé que me basta con
brujulear en el "Almacen", si se usan enlaces duros, no.

Post by Camaleón
Tal y como lo interpreto, no es que no exista el archivo, es que el
servidor ftp no tiene acceso por estar enjaulado.

No, también se tiene acceso al fichero enlazado, el problema como he
dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
/srv/ftp/Almacen/fichero.txt
/srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt
Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
/srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
que funcionaría dentro del ftp (aunque no en el sistema) .

1. Crea /Almacen en la raíz. De esta manera los nuevos enlaces
simbólicos tendrán la ruta /Almacen (que corresponde con la ruta dentro
del chroot).

2. Monta con --o bind el directorio /Almacen en /srv/ftp/Almacen.

Post by José Miguel (sio2)

Post by Camaleón

Post by José Miguel (sio2)
He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
de seguir la ruta y cambiar el fichero enlazado?

Usando enlaces duros o permitiendo el flujo convencional de acceso a los
enlaces simbólicos a través de montajes con "--bind".

Lo primero ya te he dicho por qué no me convence. Lo segundo no
funciona, y la tercera solución (enlaces con ruta relativa) también
tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
con la forma; quizás, porque, simplemente, no se puede.

Espero haberme explicado.

Post by José Miguel (sio2)
Gracias.

Saludos.

[José Miguel (sio2)]

Post by Francesc Guitart
No estoy seguro de haverlo entendido bien y además me parece que mi
[...]

Siento responder tan tarde, pero no me ha acompañado la salud...

No, no se me había ocurrido. Es una solución bastante guarretera, pero
creo sí es solución (no lo he probado). Miré el RFC que me dijo
Camaleón, pero no llegué a comprender del todo por qué se comporta el
servidor FTP con los enlaces simbólicos del modo en que se comporta:

http://tools.ietf.org/html/rfc3659#section-7.5

Creo que la posible explicación está en 7.5.2, pero no saco nada en
claro. Comprobé que si el enlace simbólico y el fichero real no tienen
el mismo nombre, no funciona el enlace dentro del FTP, aunque use ruta
relativa.

Muchas gracias.
--
Flérida para mí dulce y sabrosa,
más que la fruta de cercado ajeno.
--- Garcilaso de la Vega ---

[Camaleón]

Post by José Miguel (sio2)

Post by Francesc Guitart
No estoy seguro de haverlo entendido bien y además me parece que mi
[...]

Siento responder tan tarde, pero no me ha acompañado la salud...
No, no se me había ocurrido. Es una solución bastante guarretera, pero
creo sí es solución (no lo he probado).

Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)

Post by José Miguel (sio2)
Miré el RFC que me dijo Camaleón, pero no llegué a comprender del todo
por qué se comporta el servidor FTP con los enlaces simbólicos del modo
http://tools.ietf.org/html/rfc3659#section-7.5
Creo que la posible explicación está en 7.5.2, pero no saco nada en
claro. Comprobé que si el enlace simbólico y el fichero real no tienen
el mismo nombre, no funciona el enlace dentro del FTP, aunque use ruta
relativa.

A mí tampoco me queda claro, de hecho la sección que indicas no parece
mencionar problemas con enlaces simbólicos por lo que deberían respetarse
siempre y cuando el sistema los admita y por eso creo que sería relevante
la información que te preguntaba en un correo anterior:

https://lists.debian.org/debian-user-spanish/2014/05/msg00470.html

Es decir, si (en teoría) el servidor ftp puede trabajar con enlaces
simbólicos a los que tenga acceso -que estén en su ámbito- como parece
ser el caso, sería interesante saber qué error registra cuando se intenta
sobrescribir un archivo que está apuntando a otro archivo.

Saludos,

[José Miguel (sio2)]

Post by Camaleón
Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)

Mis disculpas. Dije que el problema no estaba en que el enlace
apuntara fuera, porque, de hecho, no apunta fuera. Efectivamente se hace
un "mount -o bind", pero no se hace para que funcione el ftp, sino para
que funcione todo lo demás. Me explico: la cutre solución sería hacer
los enlaces "mal". En vez de esto:

f.txt -> /srv/ftp/Almacen/f.txt

esto:

f.txt -> /Almacen/f.txt

que es lo que ve el ftp, puesto que está enjaulado. Ahora el enlace
funcionaría en el ftp (o eso creo, no lo he probado). Lo que no
funcionaría es en el resto del sistema. Así que creamos un /Almacen y
hacemos en mount -o bind.

Post by Camaleón
A mí tampoco me queda claro, de hecho la sección que indicas no parece
mencionar problemas con enlaces simbólicos por lo que deberían respetarse
siempre y cuando el sistema los admita y por eso creo que sería relevante
https://lists.debian.org/debian-user-spanish/2014/05/msg00470.html
Es decir, si (en teoría) el servidor ftp puede trabajar con enlaces
simbólicos a los que tenga acceso -que estén en su ámbito- como parece
ser el caso, sería interesante saber qué error registra cuando se intenta
sobrescribir un archivo que está apuntando a otro archivo.

A ver. Intentaré dar respuesta. Los ficheros en el servidor son estos:

/srv/ftp/Almacen/Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f2.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2012-2013/f.txt -> /srv/ftp/Material/Contenedor/f.txt
/srv/ftp/Almacen/Curso_2012-2013/f2.txt -> /Contenedor/f.txt

El ftp está enjaulado en /srv/ftp/Material y f.txt contiene "Hola".

En el cliente creo dos ficheros f.txt y f2.txt ambos con el texto
"Adios".

#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2013-2014
ftp> put f.txt
[...]
226 Transfer complete.
#v-

Vale, sobreescribe el fichero apuntado (el enlace simbólico, intacto).

#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2013-2014
ftp> put f2.txt
[...]
226 Transfer complete.
#v-

Vale, sobreescribe el fichero apuntado.

#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2012-2013
ftp> put f.txt
[...]
553 Could not create file.
#v-

Falla. En el servidor el error es:

FAIL UPLOAD: Client "XX.XXX.XXX.XXX", "/Curso_2012-2013/f.txt", 0.00Kbyte/sec

#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2012-2013
ftp> put f2.txt
[...]
226 Transfer complete.
#v-

Vale, como era de esperar, sin ni siquiera haber hecho el mount ni
creado /Contenedor. Ahora bien, si se quiere que esos ficheros sean
descargables por web, no hay más remedio que hacerlo, porque en el
sistema el enlace simbólico no funciona:

$ cd /srv/ftp/Almacen/Curso_2012-2013
$ cat f2,txt
cat: f2.txt: No existe el fichero o el directorio

Creo que no hay ninguna incoherencia en lo que hace el servidor FTP con
los enlaces simbólicos. El problema es que al subir un fichero, busca el
fichero apuntado, en vez de sobreescribir el fichero-enlace. Por eso,
cuando el enlace apunta "a ningún fichero" (para el ftp la ruta absoluta
del enlace no existe, porque su directorio / es otro), falla.

Quizás esto tenga que ver con lo que dice el RFC. Creo entender que
cuando hay varias rutas alternativas a un fichero, para el FTP hay un
fichero, nada de un fichero regular y un enlace simbólico que apunta al
fichero regular: un fichero al que se accede por dos rutas diferentes.
Por eso intenta sobreescribir el fichero enlazado. Esa es la explicación
que quiero darle.

Saludos.
--
El hombre que se ríe de todo es que todo lo desprecia. La
mujer que se ríe de todo es que sabe que tiene una
dentadura bonita.
--- Enrique Jardiel Poncela ---

[Camaleón]

Post by Camaleón
Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)

Mis disculpas. Dije que el problema no estaba en que el enlace apuntara
fuera, porque, de hecho, no apunta fuera.

(...)

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.

Post by Camaleón
A mí tampoco me queda claro, de hecho la sección que indicas no parece
mencionar problemas con enlaces simbólicos por lo que deberían
respetarse siempre y cuando el sistema los admita y por eso creo que
https://lists.debian.org/debian-user-spanish/2014/05/msg00470.html
Es decir, si (en teoría) el servidor ftp puede trabajar con enlaces
simbólicos a los que tenga acceso -que estén en su ámbito- como parece
ser el caso, sería interesante saber qué error registra cuando se
intenta sobrescribir un archivo que está apuntando a otro archivo.

/srv/ftp/Almacen/Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f2.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2012-2013/f.txt -> /srv/ftp/Material/Contenedor/
f.txt
/srv/ftp/Almacen/Curso_2012-2013/f2.txt -> /Contenedor/f.txt
El ftp está enjaulado en /srv/ftp/Material y f.txt contiene "Hola".

Si existe una jaula (?) que impida salir de "/Material" que entiendo es
la raíz, tienes que asegurarte de que los usuarios puedan acceder al
contenido externo aunque supongo que eso ya lo habrás tenido en cuenta.
En cualquier caso, convendría que hicieras las mismas pruebas *sin* jaula
de por medio, sólo para comparar los resultados en ambos casos.

En el cliente creo dos ficheros f.txt y f2.txt ambos con el texto
"Adios".
#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2013-2014 ftp> put f.txt [...]
226 Transfer complete.
#v-
Vale, sobreescribe el fichero apuntado (el enlace simbólico, intacto).

Es decir, tenemos que:

/srv/ftp/Almacen/Curso_2013-2014/f.txt contiene "Adios"

y por ende,

/srv/ftp/Almacen/Contenedor/f.txt contiene Adios

¿correcto?

(...)

#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2012-2013 ftp> put f.txt [...]
553 Could not create file.
#v-

Falla este pero no ha fallado el primero y entiendo que es porque en el
primero no había ningún archivo anterior que tuviera que sobrescribir.

FAIL UPLOAD: Client "XX.XXX.XXX.XXX", "/Curso_2012-2013/f.txt", 0.00Kbyte/sec

¿Y ya está? :-?

Dale más verbosidad al registro del servidor FTP si te lo permite.

#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2012-2013 ftp> put f2.txt [...]
226 Transfer complete.
#v-

Este lo hace bien porque no había ningún archivo "f2.txt" que
sobrescribir ¿correcto?

Vale, como era de esperar, sin ni siquiera haber hecho el mount ni
creado /Contenedor. Ahora bien, si se quiere que esos ficheros sean
descargables por web, no hay más remedio que hacerlo, porque en el
$ cd /srv/ftp/Almacen/Curso_2012-2013
$ cat f2,txt cat: f2.txt: No existe el fichero o el directorio

Bien, pero entiendo que ese sería otro tema (digo, permitir la descarga
desde un acceso fuera de la jaula), obviamente el usuario necesita
permiso para poder acceder al recurso.

Creo que no hay ninguna incoherencia en lo que hace el servidor FTP con
los enlaces simbólicos. El problema es que al subir un fichero, busca el
fichero apuntado, en vez de sobreescribir el fichero-enlace. Por eso,
cuando el enlace apunta "a ningún fichero" (para el ftp la ruta absoluta
del enlace no existe, porque su directorio / es otro), falla.

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.

Dos pruebas adicionales que se me ocurren:

1/ Probar con un enlace duro
2/ Probar con ssh (mediante sftp)
3/ Probar con un enlace simbólico que esté en el mismo directorio

Quizás esto tenga que ver con lo que dice el RFC. Creo entender que
cuando hay varias rutas alternativas a un fichero, para el FTP hay un
fichero, nada de un fichero regular y un enlace simbólico que apunta al
fichero regular: un fichero al que se accede por dos rutas diferentes.
Por eso intenta sobreescribir el fichero enlazado. Esa es la explicación
que quiero darle.

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

Saludos,

[José Miguel (sio2)]

Post by Camaleón
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.

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.

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

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.

Post by Camaleón
[...]

#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2013-2014 ftp> put f.txt [...]
226 Transfer complete.
#v-
Vale, sobreescribe el fichero apuntado (el enlace simbólico, intacto).

/srv/ftp/Almacen/Curso_2013-2014/f.txt contiene "Adios"

Si te vas al sistema de ficheros, este fichero sigue siendo un enlace
simbólico.

Post by Camaleón
y por ende,
/srv/ftp/Almacen/Contenedor/f.txt contiene Adios
¿correcto?

Efectivamente, el cambio se ha producido en el fichero apuntado.

Post by Camaleón

#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2012-2013 ftp> put f.txt [...]
553 Could not create file.
#v-

Falla este pero no ha fallado el primero y entiendo que es porque en el
primero no había ningún archivo anterior que tuviera que sobrescribir.

No, observa que todos los enlaces simbólicos apuntan a un fichero que
existe:

/srv/ftp/Almacen/Contenedor/f.txt

A veces, La ruta es absoluta y a veces la ruta es relativa.

Post by Camaleón

FAIL UPLOAD: Client "XX.XXX.XXX.XXX", "/Curso_2012-2013/f.txt", 0.00Kbyte/sec

¿Y ya está? :-?
Dale más verbosidad al registro del servidor FTP si te lo permite.

No lo que falla es la ruta. La ruta /srv/ftp/Almacen/Contenedor/f.txt,
no es válida para el FTP, porque para el la ruta absoluta es
/Contenedor/f.txt. Esta es la razón por la que falla: yo veo coherente
el comportamiento.

Post by Camaleón

#v+
$ ftp ftp.dominio.com [...]
ftp> cd Curso_2012-2013 ftp> put f2.txt [...]
226 Transfer complete.
#v-

Este lo hace bien porque no había ningún archivo "f2.txt" que
sobrescribir ¿correcto?

No, esto no falla porque f2.txt es un enlace simbólico a f.txt con la
ruta absoluta que ve el servidor FTP:

/Contenedor/f.txt

Obviamente este enlace simbólico dentro del sistema es un enlace roto,
que no apunta a ningún fichero existente.

Ningún "put" que he hecho ha creado ningún fichero nuevo en el servidor:
todos sobreescriben el fichero regular f.txt que está en Contenedor.
Salvo el put que falla, claro.

Post by Camaleón
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.
Es más, no he hecho la prueba pero si en mi sistema existiera el
directorio:

/srv/ftp/Almacen/srv/ftp/Almacen/Contenedor/

estoy seguro que la prueba que me ha fallado no lo habría hecho.
Simplemente habría creado f.txt dentro de ese directorio. Es lo mismo
que ocurre si en un FTP vacío intento hacer:

put a/fichero.txt

Fallará porque el directorio a no existe y para poder subir el fichero a
"a", tiene que existir "a" antes.

Post by Camaleón
1/ Probar con un enlace duro

Eso va a funcionar: no veo el problema de que no lo haga.

Post by Camaleón
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.

Post by Camaleón
3/ Probar con un enlace simbólico que esté en el mismo directorio

No entiendo esto que dices.

Post by Camaleón
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.

Post by Camaleón
Saludos,

Un saludo.
--
Todos buscan quien ampare, yo quien enmiende; que más
quiero ir entendido que defendido.
--- Lope de Vega ---

[Camaleón]

Post by José Miguel (sio2)

Post by Camaleón
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.

Post by José Miguel (sio2)
/srv/ftp/Almacen/Contenedor/f.txt
/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
/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á.

Post by José Miguel (sio2)
¿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.

Post by José Miguel (sio2)
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?

(...)

Post by José Miguel (sio2)

Post by Camaleón
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.

Post by José Miguel (sio2)

Post by Camaleón
1/ Probar con un enlace duro

Eso va a funcionar: no veo el problema de que no lo haga.

Post by Camaleón
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.

Post by José Miguel (sio2)

Post by Camaleón
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/".

Post by José Miguel (sio2)

Post by Camaleón
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,

[Santiago Vila]

Post by Camaleón
Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
punteros a rutas que están fuera del alcance del servidor ftp? Se te
lleva más espacio en disco pero puedes verlo como una copia de seguridad.

Los enlaces duros, cuando se pueden hacer, *no* ocupan más que los
enlaces simbólicos.

# cd /boot
# ls -l initrd.img-3.2.0-4-amd64
-rw-r--r-- 5 root root 11994354 may 13 07:57 initrd.img-3.2.0-4-amd64
# mkdir a
# ln initrd.img-3.2.0-4-amd64 a/1
# ln initrd.img-3.2.0-4-amd64 a/2
# ln initrd.img-3.2.0-4-amd64 a/3
# ln initrd.img-3.2.0-4-amd64 a/4
# du a
11720 a

Precisamente por ser enlaces duros, solamente se guarda una copia de
entre todos los que estén enlazados entre sí, forma parte de la gracia.

Es posible incluso que ocupen menos que si fueran enlaces simbólicos,
ya que al referirse al mismo nodo-i, no gastan ni siquiera el mínimo
de 4K que suele gastar cada nodo-i.