¿Cómo obtener el control total de umask / PAM / permisos?


11

// Actualizado el 8 de febrero: cuestiones pendientes breves:

  • ¿Cómo enmascarar directorios de manera diferente a los archivos?
  • ¿Cómo enmascarar en Nautilus copiar / pegar?
  • ¿Cómo configurar umask para SSHFS?

NUESTRA SITUACIÓN

Varias personas de nuestra empresa inician sesión en un servidor y cargan archivos. Todos deben poder cargar y sobrescribir los mismos archivos. Tienen diferentes nombres de usuario, pero todos forman parte del mismo grupo. Sin embargo, este es un servidor de Internet, por lo que los "otros" usuarios deberían tener (en general) solo acceso de solo lectura. Entonces, lo que quiero tener son estos permisos estándar:

archivos: 664
directorios: 771

Mi objetivo es que todos los usuarios no tengan que preocuparse por los permisos. El servidor debe configurarse de tal manera que estos permisos se apliquen a todos los archivos y directorios, recién creados, copiados o sobrescritos. Solo cuando necesitemos algunos permisos especiales lo modificaremos manualmente.

Subimos archivos al servidor mediante SFTP-ing en Nautilus, montando el servidor usando sshfs y accediendo a él en Nautilus como si fuera una carpeta local, y SCP-ing en la línea de comandos. Eso básicamente cubre nuestra situación y lo que pretendemos hacer.

Ahora, he leído muchas cosas sobre la hermosa funcionalidad de umask. Por lo que entiendo, umask (junto con PAM) debería permitirme hacer exactamente lo que quiero: establecer permisos estándar para nuevos archivos y directorios. Sin embargo, después de muchas horas de lectura y prueba y error, todavía no consigo que esto funcione. Obtengo muchos resultados inesperados. Realmente me gusta tener una sólida comprensión de umask y tengo muchas preguntas sin responder. Publicaré estas preguntas a continuación, junto con mis hallazgos y una explicación de mis ensayos que condujeron a estas preguntas. Dado que muchas cosas parecen salir mal, creo que estoy haciendo varias cosas mal. Por lo tanto, hay muchas preguntas.

NOTA: Estoy usando Ubuntu 9.10 y, por lo tanto , no puedo cambiar el sshd_config para configurar la umask para el servidor SFTP. SSH OpenSSH_5.1p1 instalado Debian-6ubuntu2 <requiere OpenSSH 5.4p1. Así que aquí van las preguntas.

1. ¿NECESITO REINICIAR PARA QUE LOS CAMBIOS DE PAM TENGAN EFECTO?

Comencemos con esto. Había tantos archivos involucrados y no pude averiguar qué afecta y qué no afecta las cosas, también porque no sabía si tenía que reiniciar todo el sistema para que los cambios de PAM surtan efecto. Lo hice después de no ver los resultados esperados, pero ¿es esto realmente necesario? ¿O simplemente puedo cerrar sesión en el servidor y volver a iniciar sesión, y las nuevas políticas PAM deberían ser efectivas? ¿O hay algún programa 'PAM' para recargar?

2. ¿HAY UN SOLO ARCHIVO PARA CAMBIAR QUE AFECTA A TODOS LOS USUARIOS PARA TODAS LAS SESIONES?

Así que terminé cambiando MUCHOS archivos, mientras leía MUCHAS cosas diferentes. Terminé configurando la umask en los siguientes archivos:

~/.profile -> umask=0002
~/.bashrc -> umask=0002
/etc/profile -> umask=0002
/etc/pam.d/common-session -> umask=0002
/etc/pam.d/sshd -> umask=0002
/etc/pam.d/login -> umask=0002

Quiero que este cambio se aplique a todos los usuarios, por lo que sería mejor algún tipo de cambio en todo el sistema. ¿Se puede lograr?

3. DESPUÉS DE TODO, ESTA COSA DE UMASK, ¿FUNCIONA?

Entonces, después de cambiar umask a 0002 en todos los lugares posibles, ejecuto pruebas.

------------ SCP -----------

PRUEBA 1:

scp testfile (which has 777 permissions for testing purposes) server:/home/
testfile                                      100%    4     0.0KB/s   00:00   

Verifiquemos los permisos:

user@server:/home$ ls -l
total 4
-rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)

ACTUALIZACIÓN: corregido SOLO configurando umask en pam.d / common-sessions (ver comentarios)

--------- SSH ------------

PRUEBA 2:

ssh server
user@server:/home$ touch anotherfile
user@server:/home$ ls -l
total 4
-rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)

-------- SFTP -----------

Nautilus: sftp: // servidor / inicio /

Copie y pegue newfile de cliente a servidor (777 en el cliente)

PRUEBA 3:

user@server:/home$ ls -l
total 4
-rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)

Crea un nuevo archivo a través de Nautilus. Verifique los permisos de archivo en la terminal:

PRUEBA 4:

user@server:/home$ ls -l
total 4
-rw------- 1 user uploaders    0 2011-02-05 18:06 newfile (600)

Quiero decir ... ¡¿QUÉ acaba de pasar aquí ?! Nos deberíamos obtener 644 cada vez. En cambio, obtengo 711, 777, 600 y luego una vez 644. Y el 644 solo se logra al crear un nuevo archivo en blanco a través de SSH, que es el escenario menos probable.

Entonces, estoy preguntando, ¿umask / pam funciona después de todo?

ACTUALIZACIÓN: prueba fija 4 al SOLO configurar umask en pam.d / common-sessions (ver comentarios)

4. ¿Y QUÉ SIGNIFICA UMASK SSHFS?

A veces montamos un servidor localmente, usando sshfs. Muy útil. Pero nuevamente, tenemos problemas de permisos.

Así es como montamos:

sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt

NOTA: usamos umask = 113 porque aparentemente, sshfs comienza desde 777 en lugar de 666, por lo que con 113 obtenemos 664, que es el permiso de archivo deseado.

Pero lo que sucede ahora es que vemos todos los archivos y directorios como si fueran 664. Navegamos en Nautilus hasta / mnt y:

  • Haga clic derecho -> Nuevo archivo (archivo nuevo) --- PRUEBA 5
  • Haga clic derecho -> Nueva carpeta (nueva carpeta) --- PRUEBA 6
  • Copie y pegue un archivo 777 de nuestro cliente local --- PRUEBA 7

Así que veamos en la línea de comando:

user@client:/mnt$ ls -l
total 8
-rw-rw-r-- 1 user 1007    3 Feb  5 18:05 copyfile (664)
-rw-rw-r-- 1 user 1007    0 Feb  5 18:15 newfile (664)
drw-rw-r-- 1 user 1007 4096 Feb  5 18:15 newfolder (664)

Pero bueno, revisemos esta misma carpeta en el lado del servidor:

user@server:/home$ ls -l
total 8
-rwxrwxrwx 1 user uploaders    3 2011-02-05 18:05 copyfile (777)
-rw------- 1 user uploaders    0 2011-02-05 18:15 newfile (600)
drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)

¡¿Qué?! Los permisos de archivo REAL son muy diferentes de lo que vemos en Nautilus. Entonces, ¿esta umask en sshfs solo crea un 'filtro' que muestra permisos de archivos irreales? Y traté de abrir un archivo de otro usuario pero del mismo grupo que tenía 600 permisos reales pero 644 permisos 'falsos', y todavía no podía leer esto, entonces, ¿de qué sirve este filtro?

5. UMASK ES TODO SOBRE ARCHIVOS. ¿Pero qué hay de los directorios?

De mis pruebas puedo ver que la umask que se está aplicando también influye de alguna manera en los permisos del directorio. Sin embargo, quiero que mis archivos sean 664 (002) y mis directorios sean 771 (006). Entonces, ¿es posible tener una umask diferente para los directorios?

6. Quizás UMASK / PAM ES REALMENTE FRESCO, ¿PERO UBUNTU ES SOLO BUGGY?

Por un lado, he leído temas de personas que han tenido éxito con PAM / UMASK y Ubuntu. Por otro lado, he encontrado muchos errores más antiguos y más nuevos con respecto a umask / PAM / fuse en Ubuntu:

Entonces ya no sé qué creer. ¿Debería rendirme? ¿ ACL resolvería todos mis problemas? ¿O tengo problemas nuevamente con Ubuntu?

Una palabra de precaución con las copias de seguridad con tar. Las distribuciones de Red Hat / Centos admiten acls en el programa tar, pero Ubuntu no admite acls al realizar una copia de seguridad. Esto significa que todas las acls se perderán cuando cree una copia de seguridad.

Estoy muy dispuesto a actualizar a Ubuntu 10.04 si eso también soluciona mis problemas, pero primero quiero entender lo que está sucediendo.

Respuestas:


3

Muchas cosas podrían estar sucediendo aquí.

Primeros pensamientos:

  • sí, los cambios pam.d entran en vigencia inmediatamente
  • /etc/pam.d/common-session es el mejor lugar para establecer un valor predeterminado umask
  • cualquier entrada de pam.d umask quedaría anulada por cualquier entrada .bashrc,
    pero .bashrcsolo se leería bajo ciertas circunstancias (shell interactivo sin inicio de sesión)
  • testfile (711) es muy extraño
    • ¿Cómo se /homemonta y está utilizando ACL?
      (por ejemplo, ¿qué hacer ls -ld /homee getfacl /homeimprimir?)
    • hizo testfileya existen antes que tú la copia, porque scpno va a cambiar los permisos de un archivo que ya existía (a menos que utilice la -pbandera)
  • Se sabe que Nautilus crea archivos de una manera diferente, no estoy seguro de por qué o cuáles son las reglas
  • umask=0113 probablemente causará problemas
  • ¿El servidor y el cliente ejecutan el mismo sistema operativo?
    por ejemplo, si el cliente tiene ACL habilitadas, o es Cygwin, el comportamiento puede ser diferente
  • la mejor manera de forzar permisos sanos es usar ACL predeterminadas, exactamente porque, como descubrió, umaskel usuario puede anularlas en .bashrcy .bash_profile.

Actualizar:

  • umask=0113 porque sshfs está mal.
    1. Intente montar sin especificar un umask
    2. Cree un nuevo archivo dentro del punto de montaje usando touch.
    3. Debería ver que solo se pone -rw-r--r--, por ejemplo , sin xbits
    4. Al enmascarar xbits, es posible que rompa directorios
      y que los compiladores no puedan crear archivos ejecutables correctamente

Solución alterna:

Si no podemos pensar en nada mejor, puede usar famo gaminobservar la creación de nuevos archivos y corregir los permisos, o incluso solo un script que se ejecuta periódicamente y establece los permisos en todos los archivos.


¡Gracias! OK, así que eliminé TODAS las configuraciones de umask excepto pam.d / common-sessions. ¡Esto resolvió varios problemas! La Prueba 1 (SCP) y la Prueba 4 (Nuevo archivo en Nautilus) ahora funcionan bien. Los obstáculos ahora están copiando un archivo con cualquier permiso en Nautilus al servidor (Prueba 3 - todavía 777 en lugar de 664). Y los problemas de directorio. Tanto el servidor como el cliente son Ubuntu (9.10 vs 10.10), y no se habilitan ACL adicionales.

Parece que copiar con Nautilus preserva los permisos como cp -po lo scp -pharía.
Mikel

¿Alguna idea de cómo cambiar esto?

¿Qué comportamiento quieres? Puede establecer permisos predeterminados para archivos nuevos mediante el uso de ACL predeterminadas. Nautilus respetará la ACL predeterminada. Visite vanemery.com/Linux/ACL/linux-acl.html para obtener una descripción general y suse.de/~agruen/acl/linux-acls/online para obtener todos los detalles.
Mikel

Tenga en cuenta que las ACL predeterminadas no imponen un conjunto máximo de permisos, solo hacen que esos permisos sean los predeterminados. cp -p, scp -py la copia a través de Nautilus seguirá intentando que los permisos de la copia sean los mismos que el archivo que se está copiando.
Mikel

0

Esto no está relacionado con PAM / umask, pero podría ser útil para usted.

Si configura un directorio, todos los archivos y directorios creados dentro de él se asignan automáticamente a su grupo.

root@ricarda ~ # mkdir hello      
root@ricarda ~ # chown :users hello 
root@ricarda ~ # chmod g+s hello
root@ricarda ~ # ls -l |grep hello 
drwxr-sr-x. 2 root users  4096 Feb  7 04:05 hello
root@ricarda ~ # touch hello/some_file
root@ricarda ~ # mkdir hello/some_dir
root@ricarda ~ # ls -l hello/       
total 4
drwxr-sr-x. 2 root users 4096 Feb  7 04:16 some_dir
-rw-r--r--. 1 root users    0 Feb  7 04:06 some_file

¡Gracias! Yo no sabía sobre esto. No resuelve los problemas de permisos, ¡pero es útil de hecho!


0

Las ACL deberían funcionar bien para usted.

Establezca una ACL predeterminada en todas las carpetas para el grupo, que luego será heredada por todos los archivos y directorios futuros.

Algo así setfacl -m d:g:uploaders:rwxdebería funcionar.

Para arreglar sus permisos existentes:

find /shared/folder -type d -exec setfacl -m d:g:uploaders:rwx {} \;
find /shared/folder -type f -exec setfacl -m g:uploaders:rw {} \;

Parece que si se establece "preservar" cuando se copia un archivo, la ACL predeterminada no funciona. En ese caso, solo puedo sugerir ejecutar los comandos find en cron o monitorear el sistema de archivos en busca de cambios.

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.