[RISOLTO] - Gestione permessi webserver

[snipershady]

Ho un problema di permessi sul webserver e non riesco a capire cosa stia sbagliando.
Vengo al dunque

Debian 7.8
Kernel 3.19.2
Versione Apache 2.4.10
Versione PHP 5.5.9
MySQL 5.6

apache si avvia come www-data

virtualhost impostato per
/home/UTENTE1/public_html

joomla 3.4.1 installato  caricando i files da ftp come UTENTE1
i permessi sulla cartella risultano essere non idonei all'installazione.

sono COSTRETTO ad impostare chmod 777 (ORRORE) per poter riuscire ad installare joomla
e successivamente,  se riporto le directory e files in 755(quindi senza neanche esser troppo precisi mettendo i files in 644), andando da backend di joomla in Sistema, Informazioni di sistema, permessi cartella, risultano tutti i files "non scrivibili".

Sposto il CHMOD in 775 (danto la scrittura anche ai gruppi)... non si risolve

Aggiungo UTENTE1 al gruppo www-data

Codice: [Seleziona]

usermod -a -G www-data UTENTE1
ancora tutti i files "non scrivibil".

E' più che palese che per essere scrivibili questi files devono esser gestiti da "others"...
ci vogliono i permessi rwx anche per others

porto tutto su 777 e ovviamente il sito funzione, riesco ad installare mod etc...

cosa sbaglio?
Qualcuo sa darmi un suggerimento?

Grazie anticipatamente

[tomtomeight]

Devi interfacciare il server web con fastcgi in modo che sia questi a gestire le richieste tra apache e il sito. In rete vedi come aggiungere fastcgi  in base alla distribuzione linux e versione apache.

[mmleoni]

come gira php? perchè se non è caricato come mod_php allora non gira con lo stesso utente di apache, e quindi non importa con che utente giri apache... magari chiedi lumi all'assistenza (trovi la config in /etc/apache2/mods-enabled)

ps: mai dare i permessi come 775 o con un altro numero, se si vuole dare, ad esempio, il permesso di scrittura al gruppo si usi sempre la sintassi "g+w"

ciao,
marco

[snipershady]

come gira php? perchè se non è caricato come mod_php allora non gira con lo stesso utente di apache, e quindi non importa con che utente giri apache... magari chiedi lumi all'assistenza (trovi la config in /etc/apache2/mods-enabled)

ps: mai dare i permessi come 775 o con un altro numero, se si vuole dare, ad esempio, il permesso di scrittura al gruppo si usi sempre la sintassi "g+w"

ciao,
marco

php gira come mod-php5
Circa i permessi, scrivo "i numeri" perchè convertire binario in decimale mi viene più che naturale

Son passato da 755 a 775 e poi  a 777 (orrooore)
per evidenziare il problema. Cioè che i files su webserver hanno bisogno di permessi come "other" e né come gruppi né come user gli bastano!

vedrò di configurare il server con fastcgi, come suggerito.

ma ogni altro consiglio è ben accetto!!!

grazie

[mmleoni]

più che aggiungere UTENTE1 a www-data io imposterei il suo gruppo primario a www-data (apache gira come www-data.www-data e quindi anche php gira così)...

comunque mancano un po'di info:
proprietà completa (user.group) con cui sono scritti i file
proprietà completa della cartella che contiene la root del sito
... e così via

è un po' difficile sapere che cosa hai fatto e, soprattutto, che cosa intendevi fare 

ciao

ps: a tutti viene naturale usare l'ottale (è ottale, non decimale) ma è comunque sbagliato perché così si agisce su tutti i flags e non solo su quelli che servono.

[snipershady]

i files in
/home/UTENTE1/public_html

hanno chown UTENTE1:UTENTE1

mi consigli di cambiare il gruppo di UTENTE1 in www-data

(considera che ho già aggiunto UTENTE1 al gruppo www-data, dovrebbe ereditarme i permessi)
dici che dovrei impostarlo come "primario" ?

[mmleoni]

utente1 fa parte del gruppo www-data, ma www-data (utente) non fa parte di utente1 (gruppo) !!

... quindi apache, che è other rispetto a utente1.utente1 ha bisogno di 777 per scrivere quelle cartelle.

se vuoi tenere i permessi così come sono, allora non puoi far girare php come modulo di apache; devi ricorrere a [fast]cgi in accoppiata con suexec (il che ti permetterebbe di far girare php come utente1.utente1: 700!!)

se no deve essere utente1.www-data (per i files, e così dovrebbe funzionare sul tuo sistema), ma questo rende difficile la configurazione in caso di molteplici utenti, dato che dovresti reimpostare tutti i permessi usando anche setgid.


ps: le impostazioni di sicurezza vanno viste in relazione al server e caso per caso, quindi io mi limito ad osservare ciò che vedo ed  evito di dare consigli ad minchiam.

[snipershady]

ok, ho assegnato www-data a user1

Codice: [Seleziona]

usermod -a -G user1 www-data
cambiare il chown alle cartelle e ai files è uno schioppo...

chown -r user1:www-data /home/user1/public_html


ORA FUNZIONA con 775

e se volessi farlo girare con 755??

(diciamo che già aver eliminato i permessi ad OTHERS mi fa sentir meglio...)
ma volendo limitarli solo all'utente come di consueto con hosting condivisi?

P.s. ti ringrazio per ogni suggerimento.
Anche per avermi fatto notare che avevo messo l'utente nel gruppo sbagliato (al contrario)

[snipershady]

nuova "rogna"

se faccio
su user1
tar xvf Joomla_3.4.0_ita-Stable.tar
la directory che verrà generata  Joomla_3.4.0_ita-Stable

avrà chown user1:user1


dovrei quindi, ogni volta, avviare lo script per fare un restore delle permission.

E' ovvio che forse sto percorrendo la strada sbagliata. Non è questo il modo di configurare il webserver.

consigli?

[mmleoni]

come detto sopra devi impostare anche il bit setgid, proprio perché sia mantenuto il gruppo della cartella contenitrice e non quello dell'utente.

altrimenti devi usare la configurazione alternativa suggerita. se ricordo i pacchetti da installare in debian, tutti per apache, sono:

• mpm worker
• mod fcgid
• suexec custom
• php cgi

comunque non sono compatibili con mod_php ... ma qui si esula dalle finalità di questo forum.

ciao

[mmleoni]

ps:
per avere 755 devi usare cgi con suexec (ques'ultimo permette di far girare php come uno specifico utente) ovvero la soluzione alternativa.

[snipershady]

guarda... provo in VM e riporto (non fosse altro per segnalare il topic, eventualmente, come risolto)
(ovviamente se configuro tutto come si deve, passo alla macchina pubblica )

grazie per il tempo dedicato a questo thread

[snipershady]

no, niente!

configurato server con fast-cgi, Suexec etc...

configurato il virtual host con

SuexecUserGroup user1 user1


nulla...

ora posso avere una config di PHP.ini diversa per ogni host, ma non è cambiata la gestione dei permessi

[snipershady]

risolto parzialmente usando
quindi

-impostato www-data nel gruppo di user1
-impostato chown user1:www-data per /home/user1/public

tocco finale...

Codice: [Seleziona]

chmod g+s /home/user1/public




le fastcgi non erano la soluzione o se lo erano, avrò sbagliato qualcosa nella configurazione.


Potete impostarlo come [risolto]
a meno che qualcuno non voglia essere tanto cortese da tirar fuori nuove soluzioni e magari
una linea guida sulla configurazione di php-fpm etc

[mmleoni]

per chi si è perso g+s è il modo di impstare il più volte citato setgid bit.

ricordo a tutti che fare esperimenti con la propria vm è bello e doveroso, configurare un server di produzione è compito da sistemisti...

il risolto, comunque, devi metterlo tu, modificando il titolo del post di aperura; per il resto ti consiglierei di studiare la doc di debian, giusto un tip: se rimuovi mod_php ed installi php_gci non penso che debian ti rimuova/modifichi la configurazione in apache2.conf ...

buon lavoro.

[snipershady]

il discorso legato alla necessità di un "sysadmin" per gestire un webserver è esteso a tutti.
Perchè smanettare sulle proprie VM è un conto, ma i server di produzione son ben altra cosa e son soggetti a ben altri intoppi.

Va da se, che è evidente che su questo forum difficilmente vengono trattati temi di questo tipo, visto che è più rivolto a sviluppatori che sistemisti (motivo per cui ci si prova a ragionar su insieme in cerca della giusta imbeccata).

Taggo come risolto! (anche se, a mio avviso, la soluzione che ho trovato, non è certo "LA soluzione definitiva").
Ovvio che un sysadmin esperto di apache ha tutt'altre competenze in materia!

Vado avanti con lo studio del pacchetto.