facl, setfacl, directorio compartido, ¿por qué cp pone los permisos del archivo original en la máscara facl? ¿No debería ' t ser un comportamiento cp -p?

Los usuarios de este sistema son cuidadosos y tienen sus umasks configuradas en el muy privado 0077. Sin embargo, a los usuarios les gustaría tener directorios específicos de grupo, donde los archivos se pueden copiar para compartirlos explícitamente solo entre otros miembros del grupo. Puede haber varios directorios compartidos de este tipo, aunque cada uno es específico de un grupo.

No es suficiente configurar el sticky bit de grupo en un directorio determinado para usarlo para compartir. Si bien la configuración del bit adhesivo hace que la propiedad del grupo sea correcta en los archivos colocados en el directorio, los permisos sobre dichos archivos a menudo se establecen de manera que los archivos no se pueden leer ni editar, es decir, no se pueden compartir. Simplemente aparecen en la lista del directorio. Esto se debe a que algunos usuarios no piensan o no saben cómo realizar manualmente el ajuste de permisos de grupo necesario para permitir la lectura y escritura. Podemos darles un respiro en esto porque los usuarios no son administradores, después de todo. acls se puede utilizar para especificar que un grupo en particular tiene acceso a los archivos en el directorio compartido, independientemente de los permisos del grupo sin acls. Esa es la solución perfecta, pero no funciona del todo.

A continuación, el grupo compartido es «customer_gateway» y el usuario de ejemplo que intenta compartir un archivo es «svw». Como puede verse en la transcripción, el usuario de svw es miembro del grupo customer_gateway. El directorio donde se va a compartir también se llama «customer_gateway /»

Lo siguiente usa acls. Configuro los permisos de grupo, los permisos de grupo predeterminados, la máscara y la máscara predeterminada. Funciona bien para archivos creados en el directorio, o para archivos movidos allí a través de cat (o tar), pero extrañamente, no para archivos que «cp» editan allí:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

Lo que esto muestra es que cuando se crea un archivo en el directorio, recibe los permisos predeterminados y se puede compartir. Pero los usuarios no siempre crean sus archivos allí, comúnmente los copian allí.

Pero hacer una copia es lo mismo, porque para hacer una copia primero debemos crear un nuevo archivo. Estamos hablando de una copia simple aquí, no una copia de permisos de conservación. Es lo mismo que el siguiente formulario, que, por cierto, funciona y copia un archivo que se podrá compartir en el directorio independientemente de sus permisos de grupo originales:

cat < data.in > shared/data.out 

funciona bien, la canalización a través de tar también funciona, pero el formulario

cp data.in shared/data.out 

falla. El cat El archivo ed obtiene la máscara y los permisos predeterminados. El archivo cp ed conserva sus permisos en la máscara acl y los permisos de grupo, como si fuera un cp -p (pero no era «t») y, por lo tanto, los permisos efectivos se leen como el archivo original, no como los acls se han configurado.

En un segundo intento, ejecuté este experimento con el grupo sticky bit, chmod g + rwxs, junto con el facl ch anges, y obtuve exactamente los mismos resultados. Aunque las listas de directorios son más bonitas debido a que la propiedad del grupo se muestra para todos los archivos compartidos. También lo ejecuté con solo el bit adhesivo de grupo configurado, sin setfacl. También tuvo el mismo resultado para los archivos copiados (por lo que los facls parecen bastante inútiles para un directorio en el que se copian los archivos para compartirlos).

Sobre qué base y con qué justificación distinguen los facls de Linux entre diferentes formas de creando datos? ¿Por qué obligar a cp a conservar los permisos cuando no se le ha dicho que lo haga? ¿Qué razón justificaría la confusión causada por esta distinción entre cat y piping a través del funcionamiento del alquitrán, pero cp no funciona? ¿Me estoy perdiendo un encantamiento mágico que haría esta distinción ¿evaporar?

¿Es correcto este resumen: facls le permitirá superar la propiedad para compartir archivos, hará que los permisos sean más permisivos que la umask al «crear» archivos, a menos que esa creación se deba al comando cp y por una buena razón porque … porque ¿por qué?

Comentarios

• ¿Qué sistema operativo (distribución y versión de Linux) y qué sistema de archivos estás usando? ¿Estaría bien hacer que las personas usen cat, tal vez mediante un shellscript dedicado para este propósito?
• ¿Tiene la intención de que cualquier usuario del grupo pueda modificar o eliminar cualquier archivo, o solo el creador debe tener tales permisos? En otras palabras, solo leer permisos (y tal vez ejecutar permisos) para el o usuarios.
• Debian 10. Debido a que la creación de archivos funciona, ‘ he estado canalizando copias a través de tar. Yo ‘ lo empaquetaré como un comando proj_cp en / usr / local / bin. Sin embargo, si un usuario tiene que usar un comando de copia especial, entonces uno podría simplemente ir con el bit pegajoso del grupo sin facls y establecer los permisos. Quiero saber cómo configurar los acls para que cat tar y cp funcionen.Estoy ‘ pensando que hay un problema con las acl con cp, ya que están haciendo el comportamiento cp -p en lugar del comportamiento cp. Yo ‘ espero escuchar a los expertos en permisos.
• La participación en grupo es un problema recurrente con variaciones, como usted señala. En este caso, los desarrolladores de software tienen acceso al directorio de versiones de prueba. Es de ellos para jugar. Pueden trabajar en ese directorio, empujar, extraer, instalar en el entorno virtual, etc. El problema surge cuando copian cosas de otra área en la que han estado trabajando y sus umasks no están configuradas con permisos de grupo. Es confuso para ellos porque la creación y copia de archivos por tar funciona bien. También es gracioso que tenga que darles un guión de copia que simplemente hace lo que hace cp. ‘ acls ‘ son mágicos, digo LOL
• No soy un experto en permisos, pero espero que mis preguntas y tus respuestas pueden ayudar a los expertos a darte respuestas relevantes.