Cómo permitir que los usuarios transfieran archivos a otros usuarios en Linux


10

Tenemos un entorno de unos pocos miles de usuarios que ejecutan aplicaciones en aproximadamente 40 clústeres que varían en tamaño desde 20 nodos de cómputo hasta 98,000 nodos de cómputo. Los usuarios de estos sistemas generan archivos masivos (a veces> 1PB) controlados por los permisos tradicionales de Unix (las ACL generalmente no están disponibles o son prácticas debido a la naturaleza especializada del sistema de archivos).

Actualmente tenemos un programa llamado "dar", que es un programa suid-root que permite a un usuario "dar" un archivo a otro usuario cuando los permisos de grupo son insuficientes. Entonces, un usuario escribiría algo como lo siguiente para dar un archivo a otro usuario:

> give username-to-give-to filename-to-give ...

El usuario receptor puede usar un comando llamado "take" (parte del programa give) para recibir el archivo:

> take filename-to-receive

Los permisos del archivo se transfieren efectivamente al usuario receptor.

Este programa ha existido durante años y nos gustaría revisar las cosas desde un punto de vista funcional y de seguridad.

Nuestro plan de acción actual es eliminar la putrefacción de bits en nuestra implementación actual de "dar" y empaquetarlo como una aplicación de código abierto antes de volver a implementarlo en producción.

¿Alguien tiene otro método que usan para transferir archivos extremadamente grandes entre usuarios cuando solo están disponibles los permisos tradicionales de Unix?


1
¿Hay alguna razón por la que no puede simplemente crear un directorio compartido donde todos los usuarios tengan acceso?
Zoredache

1
Si hay un directorio con acceso compartido, los usuarios sin permiso tendrían acceso a los archivos a medida que se comparten. En este entorno, a veces los nombres de archivo también son confidenciales. Entonces, desafortunadamente, un directorio compartido no es una opción. Con un directorio compartido, también existe la posibilidad de que un tercer usuario manipule el archivo.
Jon Bringhurst

¿No sería suficiente que un trabajo cron copiara los archivos? Ejemplo: el usuario foo quiere dar una barra de archivos al cachorro del usuario. entonces crea un directorio especializado que es escaneado por el trabajo cron con un archivo 'control' que contiene el nombre de usuario receptor. Los trabajos cron leerían este archivo de 'control', si el usuario está bien, el directorio de destino tiene espacio está bien, la copia. Todavía puede crear un contenedor para 'dar' para simplemente crear el archivo 'control' para tener compatibilidad histórica. No es necesario suid-root, puede copiar ese archivo en un usuario no root y luego sudo para cambiar la propiedad.
jirib

Si solo desea cambiar los permisos, chowndebe hacerlo. Parece que también desea copiar el archivo, una vez que ambas partes involucradas hayan acordado.
zebediah49

@JiriXichtkniha Me gusta la idea de un archivo de control y un trabajo cron. Sin embargo, los archivos son demasiado grandes para ser copiados.
Jon Bringhurst

Respuestas:


1

Si el emisor está realmente dispuesto a entregar el archivo, puede usar un binario SUID que mueva el archivo a un directorio que todos puedan escribir y tenga el bit adhesivo (como /tmp), luego cambie la propiedad al nuevo propietario. chown(3)ya se encarga de eliminar los bits set-user-IDy set-group-IDpara usted. De esta manera, el nuevo propietario puede hacer lo que quiera con el archivo, incluido moverlo.

Este directorio que todos pueden escribir puede pertenecer al directorio de inicio del usuario, en caso de que desee utilizar varios sistemas de archivos para directorios de inicio y asegurarse de no cruzar los límites del sistema de archivos, ya que el rendimiento sería inmediatamente terrible. En este caso, probablemente querrá asegurarse de que el destinatario sepa cuándo se ofrece un nuevo archivo.

Los correos electrónicos harían el truco. Una solución más de Unixy sería una /etc/profilelista de sus archivos recién entregados. Bonificación adicional si ofrece esta función con pam_echo( por ejemplofile=/tmp/deliveries/%u , con , ver pam_echo(8)). Al igual que con cualquier cosa relacionada con PAM, querrá verificar que todas sus implementaciones ofrezcan dicho módulo primero.


0

Podría usar un sistema con un directorio compartido (posiblemente sin permisos de ejecución), donde las cosas para un usuario determinado se archivan con una estructura de nombre de archivo específica ( to-$username_from-$username.tarpor ejemplo). Give hace el archivo y chownslo envía al usuario objetivo; tomar extrae el archivo y lo elimina.

Si desea hacerlo como un movimiento real (es decir, cambiar la ubicación y los permisos del archivo; no se debe copiar debido al tamaño de archivo gigante), es posible que pueda moverse a un directorio compartido con permisos -x (para que nadie pueda lista de archivos allí), y el mismo chownmétodo. mv, chown/ mv.


0

Como dice xryl669, puede usar un directorio para compartir realmente los archivos. Debe tener un aspecto como este:

$ ls -ld shared
drwxrws--- 2 root usergroup 4096 somedate shared
$ ls -l shared
drwx-wx--- 2 user1 usergroup 4096 somedate user1
drwx-wx--- 2 user2 usergroup 4096 somedate user2
drwx-wx--- 2 user3 usergroup 4096 somedate user3
drwx-wx--- 2 user4 usergroup 4096 somedate user4

El comando dar se convierte

#!/bin/sh
#Use a random suffix to prevent guessing
RANDOM=$(dd if=/dev/urandom count=4 2> /dev/null | sha512sum | cut -d' ' -f1)
NEWNAME=/path/to/shared/$2/$1$RANDOM
#Move the file
mv $1 $NEWNAME
#Make it readable
chmod 440 $NEWNAME

El comando take se parece a esto:

$ cd /path/to/shared/user
$ ls
...
$ mv somefile ~

0

Sugeriría reescribir la aplicación para imitar un "dar" y "tomar", sino "empujar" y "tirar" de un directorio protegido. Su directorio solo puede ser accesible para la aplicación push / pull, que maneja los movimientos del archivo. Alternativamente, su aplicación / script puede crear un directorio temporal aleatorio con permisos establecidos solo para el remitente y el receptor.

¿Desea tener más seguridad? Puede encriptar / firmar PGP el archivo (usando la clave pública del receptor).

En términos de rehacerlo desde un "punto de vista funcional y de seguridad", sugiero encarecidamente no crear programas SUID. Si no elimina los privilegios de manera adecuada, puede acceder virtualmente a cualquier archivo en el sistema. Si su programa tiene errores (desbordamiento del búfer, etc.), se puede aprovechar esto para obtener acceso a la raíz en su sistema.


0

Probablemente no le sirva de nada, pero para referencia cp --reflink source target hace copias delgadas de archivos usando copy-on-write.

Esto significa que puede copiar el archivo directamente y solo se copiarán los bloques modificados. A diferencia de un enlace rígido, el nuevo archivo tiene su propio inodo y metadatos, lo que significa que puede proporcionar la copia del archivo al nuevo usuario utilizando material estándar.

Hasta donde sé, esta es una característica que solo está disponible en OCFS2 y btrfs actualmente. Supongo que eso resuelve su problema, pero dado que la disponibilidad no está muy extendida, probablemente no sea útil.

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.