usuario sftp chrooteado con permisos de escritura en / var / www


10

Me estoy confundiendo acerca de esta configuración que estoy tratando de implementar. Espero que alguien de ustedes me pueda echar una mano: muy apreciado.

Información de fondo

El servidor es Debian 6.0, ext3, con Apache2 / SSL y Nginx en el frente como proxy inverso. Necesito proporcionar acceso sftp al directorio raíz de Apache (/ var / www), asegurándome de que el usuario sftp esté conectado a esa ruta con permisos RWX.

Todo esto sin modificar ningún permiso predeterminado en / var / www.

drwxr-xr-x  9 root root  4096 Nov  4 22:46 www

Dentro / var / www

-rw-r----- 1 www-data www-data     177 Mar 11  2012 file1
drwxr-x--- 6 www-data www-data    4096 Sep 10  2012 dir1
drwxr-xr-x 7 www-data www-data    4096 Sep 28  2012 dir2
-rw------- 1 root     root          19 Apr  6  2012 file2
-rw------- 1 root     root     3548528 Sep 28  2012 file3
drwxr-x--- 6 www-data www-data    4096 Aug 22 00:11 dir3
drwxr-x--- 5 www-data www-data    4096 Jul 15  2012 dir4
drwxr-x--- 2 www-data www-data  536576 Nov 24  2012 dir5
drwxr-x--- 2 www-data www-data    4096 Nov  5 00:00 dir6
drwxr-x--- 2 www-data www-data    4096 Nov  4 13:24 dir7

Lo que he intentado

  1. creó un nuevo grupo secureftp
  2. creó un nuevo usuario sftp, se unió a los grupos secureftp y www-data también con nologin shell. Homedir es /
  3. editado sshd_config con
Subsystem sftp internal-sftp 
AllowTcpForwarding no 
Match Group <secureftp> 
      ChrootDirectory /var/www 
      ForceCommand internal-sftp

Puedo iniciar sesión con el usuario sftp, enumerar archivos pero no se permite ninguna acción de escritura. El usuario de Sftp está en el grupo www-data pero los permisos en / var / www son read / read + x para el bit de grupo, así que ... No funciona.

También probé con ACL, pero a medida que aplico permisos ACL RWX para el usuario sftp a / var / www (directorios y archivos de forma recursiva), también cambiará los permisos de Unix, que es lo que no quiero.

Que puedo hacer aqui

Estaba pensando que podría permitir que el usuario www-data inicie sesión como sftp, para que pueda modificar los archivos / directorios que posee www-data en / var / www. Pero por alguna razón, creo que este sería un movimiento estúpido en términos de seguridad.


No creo que sea posible sin cambiar el permiso.
Unnikrishnan

Respuestas:


15

Lo que he hecho es convertir a mis usuarios en sus directorios de inicio y luego usarlos mount --bindpara crear un enlace en sus directorios de inicio.

Luego solía setfaclasegurarme de que los www-datamantenedores escriben permisos en los nuevos archivos del directorio. Este efecto se repetirá /var/www, que es lo que quieres hacer.

Al configurar g+sel directorio, todos los archivos y directorios nuevos creados dentro de él heredarán la propiedad del grupo de su padre.

useradd someuser
mkdir -p /home/someuser/www
mount --bind /var/www /home/someuser/www
chmod g+s /home/someuser/www
chown -R someuser:www-data /home/someuser/www
setfacl -d -m g::rwx /home/someuser/www

Eso debería hacer el truco.

Haz que tus monturas sean persistentes

Obviamente, desea que sus monturas sigan allí cuando reinicie el servidor. Es tan simple como agregar las monturas a tu /etc/fstab. No todos los proveedores le permiten tocar este archivo, pero la mayoría sí.

Simplemente agregue líneas como esta:

/var/www        /home/someuser/www        none        bind        0        0

Es posible que desee reiniciar para asegurarse de que funciona.


1
El hecho es que cuando chmod g + s / home / someuser / www y chown someuser: www-data / home / someuser / www también transferirá los mismos permisos y propietario: grupo a / var / www. Esto se debe al montaje --bind. ¡Muchas gracias!
bashintosh

2
¿Dónde puedo pagarte una cerveza? Parece que todo está bien, y Apache no parece quejarse de sftp-user como propietario de / var / www. Estaba muy cerca de su solución cuando tomé el camino de ACL, pero dejé la parte suida: eres mágico, ¡gracias!
bashintosh
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.