Estoy usando Debian 7 y he creado un nuevo usuario (sitio web) con un directorio htdocs como este:
$ sudo adduser website
$ sudo mkdir -p /home/website/htdocs
$ sudo chown -R website /home/website
Ahora me gustaría que los usuarios de otro grupo (desarrolladores) tuvieran acceso al directorio del usuario. He probado:
$ sudo chown -R :developers /home/website
Puedo ver que el grupo está asignado (con ls -la o stat ) y que los usuarios están en el grupo, pero no tienen acceso, ¿verdad?
drwxr-xr-x 3 website developers 4096 May 3 09:09 website
También quiero:
-
Permitir que otro grupo, 'contratistas', acceda a los archivos del sitio web
-
Restrinja el acceso de los usuarios del sitio web solo a sus directorios de inicio
-
Asegúrese de que los nuevos archivos del sitio web hereden estos permisos
¿Tiene que usar listas de control de acceso, o hay una mejor manera de hacerlo (como no usar un usuario separado para cada sitio)?
Respuesta aceptada:
Es difícil dar comandos precisos sin conocer el sistema operativo o la distribución; ¡y si! ACL funcionaría, pero también hay una forma estándar.
Hay adduser y useradd , uno de ellos en su distribución puede crear el directorio de inicio del usuario automáticamente. Si es así, entonces el contenido de /etc/skel/ El directorio se copiaría en el directorio de inicio del usuario, se establecerían los permisos y tal vez se podrían realizar algunas otras acciones apropiadas.
Puede haber grupos predefinidos para compartir, como "personal"; pero, si queremos crear nuestro propio grupo para compartir, no tiene nada de malo. Entonces, cree un nuevo grupo o use un grupo existente. Asegúrese de que los usuarios que van a ser miembros del grupo hayan sido definidos como tales con usermod , moduser , o vigr tal vez, según el sistema operativo. Cada usuario que haya iniciado sesión actualmente debe cerrar sesión y volver a iniciar sesión para convertirse en miembro de un nuevo grupo.
Cree un directorio común para todos los usuarios, como /home/share_directory/ o cualquier otro directorio que tenga más sentido para su situación. Una práctica recomendada relevante es no usar un directorio dentro el directorio de inicio de cualquier usuario. Si nadie, excepto el propietario y el grupo, debe poder ver los archivos en el directorio, entonces cambie los permisos del directorio a 0770. Si la lectura está bien para "otros", entonces use 0775. El propietario del directorio casi con seguridad debería ser root.
chown root:group_name /home/share_directory/
A continuación, cambie el bit setuid.
chmod +s /home/share_directory/
Si ningún usuario debe poder modificar el archivo de otro usuario, configure también el bit de control.
chmod +t /home/share_directory/
Estos ejemplos configuran los bits setuid y sticky al mismo tiempo usando notación octal.
chmod 5775 /home/share_directory/
o
chmod 5770 /home/share_directory/
Para la pregunta actualizada, parece que ACL es la herramienta adecuada. La mayoría de las distribuciones de Linux ahora incluyen el acl opción en los defaults opción. Si su distribución no incluye el acl opción predeterminada, entonces se necesita un poco de trabajo para comenzar a usarlo. Primero monte los sistemas de archivos con el acl opción en /etc/fstab.
sudo vim /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,acl 0 1
Si es necesario, vuelva a montar el sistema de archivos:sudo mount -o remount,acl / . Luego haga un grupo al que pueda pertenecer un usuario para este propósito. Es posible que también deba instalar las herramientas de ACL:apt-get install acl .
sudo groupadd developers
sudo usermod -a -G developers $username
(O el grupo podría ser "contratistas".) Un usuario conectado actualmente debe cerrar sesión y volver a iniciar sesión para convertirse en miembro del nuevo grupo. Por supuesto, no haga esto si tiene contenido en el directorio /var/www que desea conservar, pero solo para ilustrar cómo configurarlo para que comience:
sudo rm -rf /var/www
sudo mkdir -p /var/www/public
sudo chown -R root:developers /var/www/public
sudo chmod 0775 /var/www/public
sudo chmod g+s /var/www/public
sudo setfacl -d -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -d -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
Arriba, la diferencia entre setfacl Los comandos son estos:la primera instancia usa el grupo predeterminado (grupo propietario del directorio) mientras que la segunda especifica un grupo explícitamente. El -d switch establece la máscara por defecto (-m ) para todos los nuevos objetos del sistema de archivos dentro del directorio. Sin embargo, también necesitamos ejecutar el comando nuevamente sin -d cambiar para aplicar la ACL al propio directorio. Luego reemplace las referencias a "/var/www" con "/var/www/public" en un archivo de configuración y vuelva a cargar.
sudo vim /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 reload
Si quisiéramos restringir eliminar y renombrar a todos excepto al usuario que creó el archivo:sudo chmod +t /var/www/public . De esta forma, si queremos crear directorios para marcos que existen fuera de la raíz de documentos de Apache o tal vez crear directorios en los que se pueda escribir en el servidor, sigue siendo fácil.
Directorio de registros editables por Apache:
sudo mkdir /var/www/logs
sudo chgrp www-data /var/www/logs
sudo chmod 0770 /var/www/logs
Directorio de la biblioteca legible por Apache:
sudo mkdir /var/www/lib
sudo chgrp www-data /var/www/logs
sudo chmod 0750 /var/www/logs
Un poco de "reproducción" en un directorio que no importa debería ayudar a que esto sea correcto para su situación.
En cuanto a las restricciones, utilizo dos enfoques diferentes:el shell, rssh , se hizo para proporcionar acceso SCP/SFTP pero no acceso SSH; o, para restringir el uso a un directorio de inicio, puede usar el subsistema internal-sftp, configurado en /etc/ssh/sshd_config .
Subsystem sftp internal-sftp
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Cree un grupo denominado, por ejemplo, sftponly. Haga que los usuarios sean miembros del grupo sftponly. Cambie sus directorios de inicio a / debido al chroot. El directorio, /home/username, debe ser propiedad de root. También puede configurar el shell del usuario en /bin/false para evitar el acceso SSH. Principalmente me preocupa el acceso interactivo, por lo que generalmente voy con rssh sendero. (No pueden escribir en ningún lugar excepto donde he definido la capacidad de escritura).