utente sftp chrooted con permessi di scrittura su / var / www


10

Mi sto confondendo su questa configurazione che sto cercando di distribuire. Spero che qualcuno di voi possa darmi una mano: molto apprezzato.

Informazioni sullo sfondo

Il server è Debian 6.0, ext3, con Apache2 / SSL e Nginx nella parte anteriore come proxy inverso. Devo fornire l'accesso sftp alla directory principale di Apache (/ var / www), assicurandomi che l'utente sftp sia chroot su quel percorso con le autorizzazioni RWX.

Tutto questo senza modificare alcuna autorizzazione predefinita in / var / www.

drwxr-xr-x  9 root root  4096 Nov  4 22:46 www

All'interno / var / www

-rw-r----- 1 www-data www-data     177 Mar 11  2012 file1
drwxr-x--- 6 www-data www-data    4096 Sep 10  2012 dir1
drwxr-xr-x 7 www-data www-data    4096 Sep 28  2012 dir2
-rw------- 1 root     root          19 Apr  6  2012 file2
-rw------- 1 root     root     3548528 Sep 28  2012 file3
drwxr-x--- 6 www-data www-data    4096 Aug 22 00:11 dir3
drwxr-x--- 5 www-data www-data    4096 Jul 15  2012 dir4
drwxr-x--- 2 www-data www-data  536576 Nov 24  2012 dir5
drwxr-x--- 2 www-data www-data    4096 Nov  5 00:00 dir6
drwxr-x--- 2 www-data www-data    4096 Nov  4 13:24 dir7

Quello che ho provato

  1. creato un nuovo gruppo secureftp
  2. creato un nuovo utente sftp, unito a secureftp e ai gruppi www-data anche con shell nologin . Homedir è /
  3. modificato sshd_config con
Subsystem sftp internal-sftp 
AllowTcpForwarding no 
Match Group <secureftp> 
      ChrootDirectory /var/www 
      ForceCommand internal-sftp

Posso accedere con l'utente sftp, elencare i file ma non è consentita alcuna azione di scrittura. L'utente Sftp è nel gruppo www-data ma i permessi in / var / www sono letti / letti + x per il bit di gruppo, quindi ... Non funziona.

Ho anche provato con ACL, ma quando applico i permessi ACL RWX per l'utente sftp a / var / www (dirs e file ricorsivamente), cambierà anche i permessi unix, che è ciò che non voglio.

Cosa posso fare qui?

Pensavo di poter consentire all'utente www-data di accedere come sftp, in modo da poter modificare i file / directory che www-data possiede in / var / www. Ma per qualche ragione penso che sarebbe una mossa stupida dal punto di vista della sicurezza.


Non credo sia possibile senza modificare l'autorizzazione.
Unnikrishnan,

Risposte:


15

Quello che ho fatto è di trasferire i miei utenti alle loro home directory e poi mount --bindcreare un link ad esso nelle loro home directory.

Quindi mi setfaclassicuravo che i www-datamaintan scrivessero le autorizzazioni per i nuovi file nella directory. Questo effetto si ripeterà /var/www, che è quello che vuoi fare.

Impostando g+ssulla directory, tutti i nuovi file e directory creati al suo interno erediteranno la proprietà del gruppo dal suo genitore.

useradd someuser
mkdir -p /home/someuser/www
mount --bind /var/www /home/someuser/www
chmod g+s /home/someuser/www
chown -R someuser:www-data /home/someuser/www
setfacl -d -m g::rwx /home/someuser/www

Questo dovrebbe fare il trucco.

Rendi i tuoi supporti persistenti

Ovviamente vuoi che i tuoi mount siano ancora lì quando riavvii il server. È semplice come aggiungere i supporti al tuo /etc/fstab. Non tutti i provider ti consentono di toccare questo file, ma molti lo fanno.

Aggiungi solo linee come questa:

/var/www        /home/someuser/www        none        bind        0        0

Potresti voler riavviare per assicurarti che funzioni.


1
Il fatto è che quando chmod g + s / home / someuser / www e chown someuser: www-data / home / someuser / www trasferirà anche le stesse autorizzazioni e proprietario: group su / var / www. Ciò è dovuto al mount --bind. Molte grazie!
bashintosh,

2
Dove posso pagarti una birra? Sembra tutto a posto, e Apache non sembra lamentarsi di sftp-user come proprietario di / var / www. Ero molto vicino alla tua soluzione quando ho scelto ACL, ma ho lasciato fuori la parte del suid: sei magico, grazie!
bashintosh,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.