Entre los desafíos de administrar Linux en el entorno empresarial moderno está la expectativa de que podemos y debemos administrar quién tiene acceso a qué información. Érase una vez, las únicas personas que necesitaban acceso a los sistemas de archivos de Linux podían clasificarse de una manera general:a través de los permisos del sistema de archivos de Linux.
Repasando los conceptos básicos
El sistema de archivos de Linux nos da tres tipos de permisos. Aquí hay una revisión simplificada:
- T ser (o propietario del usuario)
- G grupo (o grupo propietario)
- O ellos (todos los demás)
Con estos permisos, podemos otorgar tres (en realidad cinco, pero hablaremos de eso en un minuto) tipos de acceso:
- R cabeza
- M rito
- eX ejecutar
Estos niveles de acceso suelen ser adecuados en muchos casos. Digamos que tiene un directorio donde viven los archivos del departamento de contabilidad. Puede configurar estos permisos para:
drwxrwxr-x 2 accounting accounting 12 Jan 8 15:13
El usuario del servicio de contabilidad (el propietario del usuario) puede leer y escribir en el directorio, y los miembros de accounting grupo (o grupo propietario) puede leer y escribir. Sin embargo, otros (usuarios que no pertenecen al departamento de contabilidad) pueden ver y ejecutar lo que hay allí, lo que algunos podrían pensar que es una mala idea.
[ También popular: Conceptos básicos de administrador de sistemas de Linux:administración de cuentas de usuario]
Entonces, podríamos cambiar los permisos a esto:
drwxrwx--- 2 accounting accounting 12 Jan 8 15:13 .
Ver la ACL actual
¿Qué sucede si tiene un pasante de contabilidad (Kenny) que necesita poder leer ciertos archivos (o incluso solo los archivos que pertenecen a Fred, su gerente)? O tal vez las personas del departamento de ventas también necesiten acceso a la accounting archivos del propietario para crear facturas para el equipo de Fred con el fin de facturar a los clientes, pero no desea que el equipo de ventas vea los otros informes que genera el equipo de Fred. Esta situación puede ser complicada porque, con permisos regulares, cada archivo y directorio puede tener solo un propietario de usuario y grupo a la vez. Este tipo de situación es lo que las Listas de control de acceso (ACL) de Linux pretendían resolver.
Las ACL nos permiten aplicar un conjunto más específico de permisos a un archivo o directorio sin (necesariamente) cambiar la propiedad y los permisos básicos. Nos permiten "añadir" acceso para otros usuarios o grupos.
Podemos ver la ACL actual usando getfacl comando:
[root]# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
Podemos ver que en este momento, no hay ACL en este directorio porque los únicos permisos enumerados son para el usuario, el grupo y otros. En este caso, eso es de esperar, porque acabo de crear este directorio en el laboratorio y no he hecho nada más que asignar la propiedad. Entonces, comencemos agregando una ACL predeterminada:
Configurar una ACL
La sintaxis para establecer una ACL se ve así:
setfacl [option] [action/specification] file
La 'acción' sería -m (modificar) o -x (eliminar), y la especificación sería el usuario o grupo seguido de los permisos que queremos establecer. En este caso, usaríamos la opción -d (predeterminado). Entonces, para establecer la ACL predeterminada para este directorio, ejecutaríamos:
[root]# setfacl -d -m accounting:rwx /accounting
Después de lo cual ahora podemos ver la información de ACL predeterminada para ese directorio:
[root]# getfacl /accounting
[root]# getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
default:user::rwx
default:user:accounting:rwx
default:group::rwx
default:mask::rwx
default:other::---
¿Qué pasa si Fred crea un archivo en ese directorio?
[fred]$ touch test
[fred]$ ls -la
drwxrwx---+ 2 accounting accounting 18 Jan 8 17:51 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
-rw-rw----+ 1 fred accounting 0 Jan 8 17:51 test
[fred]$ getfacl test
# file: test
# owner: fred
# group: accounting
user::rw-
user:accounting:rwx #effective:rw-
group::rwx #effective:rw-
¿Qué sucede si Kenny intenta crear un archivo? Es posible que puedas adivinarlo porque kenny no está en la accounting grupo, no tendrá permiso. Pero queremos que Kenny tenga una buena experiencia trabajando con nosotros, por lo que debemos darle la capacidad de ver qué archivos hay en la accounting. directorio, y queremos que pueda crear nuevos archivos:
[root@lab1 accounting]setfacl -m kenny:rwx /accounting
[root]getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx
Hasta aquí todo bien. Pero, ¿y si no queremos que este usuario cree archivos en la accounting? ¿directorio? En su lugar, solo queremos dejarle leer los archivos allí, y puede crear nuevos archivos en su propia carpeta.
[ Artículo relacionado: Conceptos básicos de administrador de sistemas de Linux:administración de cuentas de usuario con UID y GID]
Podemos configurar el acceso de Kenny en accounting carpeta como esta:
[root@lab1 accounting]# setfacl -m kenny:r-x /accounting
[root]# getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
User:kenny:r-x
Ahora hacemos de Kenny su propia carpeta, le damos propiedad y luego hacemos la accounting agrupar al propietario del grupo para que otras personas en el accounting el grupo puede ver lo que hay allí:
[root@lab1 accounting]# mkdir ./kenny
[root]# chown kenny:accounting ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:rwx
group::rwx
Has creado una carpeta dentro de la accounting grupo que es propiedad del usuario kenny . Ahora puede ver la carpeta de contabilidad, pero solo crea archivos en su propia carpeta:
[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test
Tenga en cuenta que debido a que la carpeta es propiedad de accounting grupo, cualquiera en ese grupo puede poner archivos allí. Debido a que estamos tratando con un interno, este factor probablemente esté bien. Sin embargo, ¿qué pasa si le damos a Kenny un ascenso a auditor jefe y queremos mantener su trabajo en secreto de Fred?
[root]# setfacl -m fred:- ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
¿Qué pasa si no queremos a nadie para ver en qué está trabajando Kenny?
[root]# setfacl -m g:accounting:- ./kenny
g: delante del nombre del grupo. Para los usuarios, simplemente cambie el g a una u , pero setfacl asumirá que estamos hablando de un usuario si no coloca nada en ese lugar.
Todavía tenemos que eliminar los permisos básicos para el propietario del grupo para que el resto del equipo de contabilidad no pueda husmear en los informes de Kenny:
[root]# chmod g-rwx ./kenny
[root]# ls -al
total 0
drwxrwx-wx+ 3 accounting accounting 44 Jan 9 16:38 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
drwx------+ 2 kenny accounting 18 Jan 9 17:07 kenny
-rw-rw----+ 1 root root 0 Jan 9 16:33 test
-rw-rw----+ 1 kenny accounting 0 Jan 9 16:27 test2
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
group::rwx #effective:---
[root]# su jan
[jan]$ touch ./kenny/test
touch: cannot touch ‘./kenny/test’: Permission denied
Ahora podemos administrar quién más puede ver o escribir en la carpeta de Kenny sin cambiar la propiedad. Démosle al CEO (Lisa, que no es miembro del equipo de contabilidad y no tendrá acceso al resto de la carpeta) acceso a las cosas de Kenny:
[root@lab1 accounting]# useradd lisa
[root]# setfacl -m u:lisa:rwx ./kenny
[root]# su lisa
[lisa]$ touch ./kenny/lisa
[lisa]$ ls ./kenny
lisa test
[lisa]$ touch test
touch: cannot touch ‘test’: Permission denied
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
user:lisa:rwx
group::rwx
group:accounting:---
Tenga en cuenta nuevamente que los permisos del propietario del grupo permanecen abiertos, pero el grupo de contabilidad (que sigue siendo el propietario) ya no tiene acceso a esa carpeta. Entonces, ¿quién es el dueño?
drwxrwx---+ 2 kenny accounting 30 Jan 9 17:16 kenny
Esta parte es complicada. Es útil saber que podemos retirar los permisos del propietario sin cambiar la propiedad, pero es posible que desee considerar si este es el resultado que desea.
Conclusión
Así que estos son los conceptos básicos. Las ACL pueden ser confusas, por lo que le animo a proporcionar las páginas man para setfacl y getfacl una buena lectura Hay muchas más cosas interesantes y útiles que puede hacer con estas herramientas, pero espero que ahora comprenda lo suficiente para comenzar.
[ ¿Quiere probar Red Hat Enterprise Linux? Descárgalo ahora gratis. ]