Sto usando Debian 7 e ho creato un nuovo utente (sito web) con una directory htdocs come questa:
$ sudo adduser website
$ sudo mkdir -p /home/website/htdocs
$ sudo chown -R website /home/website
Ora vorrei che gli utenti di un altro gruppo (sviluppatori) avessero accesso alla directory dell'utente. Ho provato:
$ sudo chown -R :developers /home/website
Vedo che il gruppo è assegnato (con ls -la o stat ) e che gli utenti sono nel gruppo, ma non hanno accesso giusto?
drwxr-xr-x 3 website developers 4096 May 3 09:09 website
Voglio anche:
-
Consenti a un altro gruppo, "appaltatori" di accedere ai file del sito web
-
Limita l'accesso degli utenti del sito web solo alle loro home directory
-
Assicurati che i nuovi file del sito web ereditino queste autorizzazioni
Devi usare gli elenchi di controllo degli accessi o c'è un modo migliore per farlo (come non utilizzare un utente separato per ogni sito)?
Risposta accettata:
È difficile dare comandi precisi senza conoscere il sistema operativo o la distribuzione; e sì! ACL funzionerebbe, ma esiste anche un modo standard.
C'è adduser e useradd , uno di loro sulla tua distribuzione potrebbe creare automaticamente la home directory dell'utente. Se è così, allora il contenuto di /etc/skel/ la directory verrebbe copiata nella home directory dell'utente, le autorizzazioni impostate e forse potrebbero essere eseguite altre azioni appropriate.
Potrebbero esistere gruppi predefiniti per la condivisione, come "personale"; ma, se vogliamo creare il nostro gruppo per la condivisione, non c'è niente di sbagliato in questo. Quindi, crea un nuovo gruppo o usa un gruppo esistente. Assicurati che gli utenti che devono essere membri del gruppo siano stati definiti come tali con usermod , moduser o vigr forse, a seconda del sistema operativo. Ogni utente attualmente connesso deve disconnettersi e riconnettersi per diventare un membro di un nuovo gruppo.
Crea una directory comune a tutti gli utenti, come /home/share_directory/ o qualsiasi altra directory che abbia più senso per la tua situazione. Una best practice pertinente è quella di non utilizzare una directory all'interno directory home di qualsiasi utente. Se nessuno tranne il proprietario e il gruppo dovrebbe essere in grado di vedere i file nella directory, cambia i permessi della directory in 0770. Se la lettura è ok da "altri", usa 0775. Il proprietario della directory dovrebbe quasi sicuramente essere root.
chown root:group_name /home/share_directory/
Quindi, cambia il bit setuid.
chmod +s /home/share_directory/
Se nessun utente dovrebbe essere in grado di modificare il file di un altro utente, imposta anche il bit stick.
chmod +t /home/share_directory/
Questi esempi impostano contemporaneamente i bit setuid e sticky usando la notazione ottale.
chmod 5775 /home/share_directory/
o
chmod 5770 /home/share_directory/
Per la domanda aggiornata, sembra che ACL sia lo strumento giusto. La maggior parte delle distribuzioni Linux ora include acl opzione nei defaults opzione. Se la tua distribuzione non include acl opzione per impostazione predefinita, quindi è necessario un piccolo lavoro per iniziare a usarlo. Per prima cosa monta i file system con acl opzione in /etc/fstab.
sudo vim /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,acl 0 1
Se necessario, rimontare il filesystem:sudo mount -o remount,acl / . Quindi crea un gruppo a cui un utente può appartenere per questo scopo. Potrebbe essere necessario installare anche gli strumenti ACL:apt-get install acl .
sudo groupadd developers
sudo usermod -a -G developers $username
(Oppure il gruppo potrebbe essere "appaltatori".) Un utente attualmente connesso deve disconnettersi e riconnettersi per diventare un membro del nuovo gruppo. Ovviamente, non farlo se hai contenuto nella directory /var/www che vuoi conservare, ma solo per illustrare la configurazione per iniziare:
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
Sopra, la differenza tra il setfacl i comandi sono questi:la prima istanza utilizza il gruppo predefinito (gruppo proprietario della directory) mentre la seconda specifica un gruppo in modo esplicito. Il -d switch stabilisce la maschera predefinita (-m ) per tutti i nuovi oggetti del filesystem all'interno della directory. Tuttavia, dobbiamo anche eseguire nuovamente il comando senza -d passare per applicare l'ACL alla directory stessa. Quindi sostituisci i riferimenti a "/var/www" con "/var/www/public" in un file di configurazione e ricarica.
sudo vim /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 reload
Se volessimo limitare l'eliminazione e la ridenominazione a tutti tranne all'utente che ha creato il file:sudo chmod +t /var/www/public . In questo modo, se vogliamo creare directory per framework che esistono al di fuori della root del documento Apache o magari creare directory scrivibili dal server, è ancora facile.
Directory dei log scrivibili da Apache:
sudo mkdir /var/www/logs
sudo chgrp www-data /var/www/logs
sudo chmod 0770 /var/www/logs
Directory della libreria leggibile da Apache:
sudo mkdir /var/www/lib
sudo chgrp www-data /var/www/logs
sudo chmod 0750 /var/www/logs
Un po' di "riproduzione" in una directory che non ha importanza dovrebbe aiutarti a farlo proprio per la tua situazione.
Sulle restrizioni, utilizzo due diversi approcci:la shell, rssh , è stato creato per fornire l'accesso SCP/SFTP ma non l'accesso SSH; oppure, per limitare l'uso a una home directory è possibile utilizzare il sottosistema internal-sftp, configurato in /etc/ssh/sshd_config .
Subsystem sftp internal-sftp
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Crea un gruppo chiamato, ad esempio, sftponly. Rendi gli utenti un membro del gruppo sftponly. Cambia le loro directory home in / a causa del chroot. La directory, /home/nomeutente, dovrebbe essere di proprietà di root. Puoi anche impostare la shell dell'utente su /bin/false per impedire l'accesso SSH. Per lo più sono preoccupato per l'accesso interattivo, quindi generalmente vai con rssh il percorso. (Non possono scrivere da nessuna parte tranne dove ho definito la capacità di scrittura.)