Desde un script de shell bash, estoy creando una carpeta y almacenando mysqldump allí. Estoy seguro de que no hay ningún comando relacionado con los permisos en mi script. Para permitir que otro usuario acceda a estos archivos, utilicé ACL, pero cuando intentó acceder al archivo, se le negó el permiso y el problema es con effectivelos permisos de ACL.
El propietario del directorio es olaun nuevo usuario que intenta acceder a la carpeta ubery la carpeta esgettaxi
Permisos del directorio principal
[/omega/olabooktmp]# getfacl .
# file: .
# owner: ola
# group: ola
user::rwx
user:uber:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Permisos del directorio infantil
[/omega/olabooktemp]# getfacl gettaxi/
# file: gettaxi/
# owner: ola
# group: ola
user::rwx
user:uber:rwx #effective:---
group::r-x #effective:---
mask::---
other::---
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Veo que gettaxilos permisos de la máscara de directorio nuevo son mask::---, así que creo que esto está causando un problema, pero no puedo entender completamente cómo resolver este problema.
Cualquier sugerencia será muy apreciada.
Gracias.
Respuesta1
Puedes cambiar la máscara con el siguiente comando:
setfacl -m m:rwx filename/directory
Respuesta2
Si entiendo bien su pregunta, el usuario olaestá creando archivos en el directorio:/omega/olabooktmp/gettaxi
y desea restringir el acceso a esos archivos, pero otorgando acceso al usuario uber.
Nota: /omega/olabooktmp/gettaxies propiedad deola
Comencemos sin ACL todavía:
ls -ld /omega/olabooktmp/gettaxi
drwxr-x--- 2 ola ola 4096 mars 21 08:16 /omega/olabooktmp/gettaxi
Para otorgar rwxpermiso para uberusar ACL, puede usar:
setfacl -m u:uber:rwx,d:u:uber:rwX,o:--- /omega/olabooktmp/gettaxi
Lo que permitirá uberderechos de usuario rwxen la carpeta /omega/olabooktmp/gettaxiy también otorgará rwxcomo defaulty d:. XOtorga permiso sobre archivos previamente presentes en la carpeta y otorga permisos heredados para archivar. Y también elimine otros permisos otherpara restringir, por supuesto. El propietario todavía tiene su propio permiso.
El resultado:
getfacl /omega/olabooktmp/gettaxi
getfacl: Removing leading '/' from absolute path names
# file: omega/olabooktmp/gettaxi
# owner: ola
# group: ola
user::rwx
user:uber:rwx
group::r-x
mask::rwx
other::---
default:user::rwx
default:user:uber:rwx
default:group::r-x
default:mask::rwx
default:other::---
Pruebas:
olacrea algunos archivos (ejecutarlos como root):
su - ola -c "for i in {1..3}; do date > /omega/olabooktmp/gettaxi/$RANDOM; done"
Resultado:
ls -l /omega/olabooktmp/gettaxi/
total 32
-rw-r----- 1 ola users 32 mars 21 08:43 17606
-rw-r----- 1 ola users 32 mars 21 08:43 22286
-rw-r----- 1 ola users 32 mars 21 08:42 31484
-rw-r----- 1 ola users 32 mars 21 08:43 31848
-rw-r----- 1 ola users 32 mars 21 08:42 667
-rw-r----- 1 ola users 4 mars 21 08:16 one
-rw-r----- 1 ola users 6 mars 21 08:16 three
-rw-r----- 1 ola users 4 mars 21 08:16 two
No puede ser accedido por un usuario normal (ejecutar como root):
su - debian -c "ls -l /omega/olabooktmp/gettaxi"
ls: cannot open directory '/omega/olabooktmp/gettaxi': Permission denied
Pero uber puede (ejecutarlo como root):
su - uber -c "ls -l /omega/olabooktmp/gettaxi"
total 32
-rw-r----- 1 ola users 32 Mar 21 08:43 17606
-rw-r----- 1 ola users 32 Mar 21 08:43 22286
-rw-r----- 1 ola users 32 Mar 21 08:42 31484
-rw-r----- 1 ola users 32 Mar 21 08:43 31848
-rw-r----- 1 ola users 32 Mar 21 08:42 667
-rw-r----- 1 ola users 4 Mar 21 08:16 one
-rw-r----- 1 ola users 6 Mar 21 08:16 three
-rw-r----- 1 ola users 4 Mar 21 08:16 two
Si destruye su ACL con algunas pruebas, puede eliminar todas las ACL con:
setfacl -R -b /omega/olabooktmp/gettaxi
Y empezar de nuevo.
Respuesta3
Sí, la máscara está reduciendo los permisos. El permiso efectivo es el y de un permiso y la máscara. ( user::(el usuario propietario), y otherno se ven afectados por la máscara).
Puedes cambiar la máscara con: por ejemplo setfacl -m m:r-x file-name.
Cuando haces an ls -l, si el modo termina con a +, entonces los bits del modo medio (tradicionalmente los bits de grupo) son la máscara.
A veces, los bits de modo se configuran de acuerdo con los bits de grupo en umask. Todavía no he elaborado las reglas sobre cuándo sucede esto y cuándo se usa la máscara predeterminada. Al usar cppara copiar un archivo, parece usar el archivo umask.
Una solución
Asegúrese de que los usuarios tengan su propio grupo y que esté configurado como el grupo predeterminado. Luego establezca el umasken 007.
Respuesta4
Sospecho que el comportamiento es un error. Publiqué sobre esto el mes pasado (consulte unix.stackexchange.com/questions/570795). Lo que sucede es que los permisos del archivo fuente se copian en la máscara acl mediante el comando cp. Esto es lo que hubiera esperado para cp -p, no para cp. Descubrí que puedo hacer copias usando cat.
cat afile > bfile
o mediante tuberías a través de alquitrán
(cd A; tar -cf -)|(cd B; tar-xf -)
Y las ACL se respetan como se esperaba.
También ofrecí una recompensa para que me explicaran este comportamiento de CP. Nadie lo explicó. Estoy pensando en presentar un informe de error. Es decir, este debería ser el comportamiento ´cp -p´, no el comportamiento básico de cp. (Y el sistema dedujo los puntos de recompensa a pesar de que nadie pudo dar una respuesta. Eso también me sorprendió).