Permessi File Consigliati per WordPress

23 dic 2010, 10:43:50
Visualizzazioni: 11.8K
Voti: 5

Ciao ragazzi, ho passato tantissimo tempo a cercare di risolvere questo problema. Vorrei sapere come dovrebbero essere impostati i permessi dei file in WordPress per poter utilizzare la funzione di aggiornamento automatico. Attualmente, la mia installazione di WordPress continua a chiedermi le credenziali FTP e non voglio usare quel metodo per aggiornare/installare, voglio usare PHP in modo diretto.

Alcuni dettagli:

  • il webserver e i demoni PHP fcgi girano come www-data:www-data
  • l'installazione di WordPress si trova in /home/blaenk/sites/domain.tld/

Inizialmente, ho letto che tutti i file/cartelle dovrebbero essere di proprietà del mio utente (blaenk) e scrivibili dal mio utente. Ma questo non funzionava, dopo molte ore di ricerca, qualcuno sul canale IRC mi ha suggerito di impostare tutto con proprietà www-data:www-data e questo ha funzionato. Non mi è più stato chiesto di inserire le credenziali FTP e l'installazione del plugin è avvenuta automaticamente.

Tuttavia, originariamente ho posizionato i file del sito nella mia home directory proprio perché volevo poterli scrivere/creare come utente. Ho anche aggiunto me stesso al gruppo www-data come indicato in questa guida.

Domanda

So già che i file dovrebbero essere 644 e le directory 755. Tuttavia, sembra più una questione di proprietà. Non voglio dover impostare www-data:www-data su tutto nella mia installazione di WordPress, quindi mi chiedo quali file/directory richiedono specificamente questo livello di proprietà?

MODIFICA: Credo che il motivo per cui tutto funziona sulla mia installazione WordPress di hosting condiviso, nonostante tutti i file siano di proprietà del mio utente, sia che l'hosting condiviso che uso sembra utilizzare suexec che presumibilmente esegue PHP come me, quindi in altre parole, i file sono di proprietà del webserver, per così dire.

2
Commenti

IMHO la domanda va oltre i diritti, ma riguarda anche la proprietà — il classico ´ftpuser´ e ´wwwuser´, come la maggior parte dei server Apache (giustamente) li ha. Sicuramente ci sono più strade per arrivare a Roma qui... Quindi qual è la "miglior pratica WP", la combinazione più rigida di quale (sotto)cartella assegnare a quale utente con quali diritti...?

Frank N Frank N
5 mag 2015 13:37:12

Ovviamente ci sono diversi passaggi: 1) Un file viene scaricato (attivato dal php- aka ´wwwuser´) ma dal punto di vista dei diritti è un'operazione ftp(?), 2) il file viene decompresso (diritti di creazione per ´wwwuser´), 3) i file più vecchi vengono sovrascritti (dal caricamento iniziale quasi certamente di proprietà di ftpuser...) ► forse attivare un logging php molto dettagliato e ('WP_DEBUG', true) ovviamente, per catturare tutti i "lamenti" e risolverli uno per uno?

Frank N Frank N
5 mag 2015 13:38:51
Tutte le risposte alla domanda 4
6

Per quanto ho capito, non è correlato a permessi specifici - l'Aggiornamento Automatico in generale richiede che il proprietario dei file corrisponda all'utente sotto cui gira Apache. Se questo non è il caso, ricade su altri metodi del filesystem (FTP, SSH) e quindi richiede la password.

Puoi definire le credenziali nelle costanti nel file wp-config.php così non ti verranno chieste.

Vedi Costanti per l'Aggiornamento di WordPress nel Codex.

23 dic 2010 10:59:49
Commenti

Grazie Rarst. Ho visto quell'articolo del codex, tuttavia, non voglio assolutamente usare FTP/SSH. Il motivo è che, in qualche modo, su un sito di hosting condiviso dove ho installato WordPress manualmente, tutto funziona, anche se tutto è di proprietà del mio utente. I file sono di proprietà del mio utente, ma anche di un altro gruppo che non ho creato, quindi immagino che ci sia qualche meccanismo SETGUID in atto, che probabilmente è il modo in cui il processo del webserver riesce a eseguire l'aggiornamento automatico.

Jorge Israel Peña Jorge Israel Peña
23 dic 2010 11:13:15

La mia ipotesi è che l'altra configurazione stia usando suexec quindi Apache esegue WordPress sotto il tuo account utente e non c'è alcuna discrepanza.

Rarst Rarst
23 dic 2010 11:21:19

Haha, sì, è quello che ho detto. Te lo concedo visto che sei l'unico che si è preso la briga di rispondere però. Grazie :)

Jorge Israel Peña Jorge Israel Peña
23 dic 2010 11:29:08

Bene, non è nemmeno passata un'ora dalla tua domanda e non c'è ancora una risposta perfetta - o fai corrispondere l'utente o usi FTP/SSH. A proposito, invece di aggiungere la soluzione alla tua domanda, potresti scriverla come risposta con alcuni link sull'argomento e simili? Così altri potranno trarne beneficio in futuro.

Rarst Rarst
23 dic 2010 11:34:08

Avevo intenzione di farlo originariamente, ma avevo paura che avresti pensato che stavo cercando di rubare la risposta da te o di sprecare il tuo tempo o qualcosa del genere. Lo faccio ora.

Jorge Israel Peña Jorge Israel Peña
23 dic 2010 11:38:55

No, va assolutamente bene. :) Il sistema funziona per raccogliere e promuovere risposte eccellenti e accurate, indipendentemente da chi le scrive. Risposte multiple sono buone e possono evidenziare diversi aspetti della domanda.

Rarst Rarst
23 dic 2010 11:59:06
Mostra i restanti 1 commenti
0

Nella mia domanda, ho espresso confusione sul fatto che tutto funzionasse perfettamente sul mio hosting condiviso nonostante tutti i file fossero di proprietà del mio utente, mentre sul mio VPS l'aggiornamento automatico non funzionava a meno che tutti i file non fossero di proprietà del server web.

Sono abbastanza sicuro che questo sia il risultato del mio host condiviso che utilizza suexec che essenzialmente esegue gli script come il mio utente. Quindi, in sostanza, i file sul mio host condiviso erano di proprietà del 'server web' (in realtà, il demone CGI).

In realtà sul mio VPS sto eseguendo nginx e php-fpm, quindi non ho accesso al suexec di Apache. Tuttavia, ho semplicemente configurato php-fpm per essere eseguito come me stesso, per testare la mia teoria, e ha effettivamente funzionato perfettamente con tutti i file di proprietà del mio utente. Credo che questo possa essere considerato un rischio per la sicurezza (non ne sono sicuro), quindi indagherò ulteriormente per vedere cosa posso fare in questo senso per evitare di eseguirlo come mio utente, ma almeno ora so qual è il problema!

23 dic 2010 11:43:35
0

Le tue esperienze 'miste' probabilmente derivano dal fatto che i due utenti in questione appartengano o meno allo stesso gruppo. E ovviamente dai "permessi di gruppo" che erano presenti.

Tradizionalmente in PHP, l'utente PHP (noto anche come apacheuser o webuser o cgideamon) non ha il diritto di modificare i file, cosa che può fare solo l'utente FTP (indicato come "il tuo account utente" in alcune descrizioni del codex), per rendere più difficile agli exploit di sicurezza modificare gli script.

Il che ovviamente rende impossibile qualsiasi aggiornamento basato su PHP dei file PHP. Quindi con PHP in generale, è comune cambiare la proprietà dei file dall'utente FTP all'utente PHP. Prima di farlo vale la pena notare che l'aggiornamento avviene "indossando le scarpe FTP" (poiché fornisci le credenziali). Poi l'estrazione degli zip scaricati avviene ovviamente nuovamente tramite script... beh, e poi c'è la cartella wp-content, che sicuramente viene toccata e riempita ulteriormente tramite script PHP... (immagino che tutti noi ci siamo imbattuti almeno una volta in questo problema in WP) Le cose possono diventare complicate.

in breve: Il Codex di WordPress offre una buona panoramica su Hardening File Permissions per essere il più 'avidi'/'sicuri' possibile con i permessi concessi ai file. Con account utente si intendono gli account FTP (ovvero non il demone cgi/utente php/...).

24 nov 2014 18:29:35
0
  1. Supponendo che tu abbia accesso ssh, ottieni prima l'"utente". Spesso il webserver viene eseguito come www-data ma se non sei sicuro, esegui top e puoi vedere l'"USER" di php, nginx, ecc.

  2. Questo passaggio è ovvio, ma trova dove si trovano i tuoi file. Di solito i tuoi file sono sotto /home/www-data/ ma ho notato che nginx per impostazione predefinita utilizzerà qualche altra directory che al momento non ricordo. In ogni caso, cd nella directory che contiene tutti i tuoi domini.

  3. chown -R www-data:www-data example.com Questo comando cambia in modo ricorsivo la proprietà di tutti i file sotto la directory example.com. Molto probabilmente questo non causerà problemi.

Di solito i file sono già impostati con i permessi corretti, ma dopo aver utilizzato decine di società di hosting posso dirti che occasionalmente i permessi vengono cambiati accidentalmente dai sysadmin, è un dato di fatto. Ad esempio, il montaggio con sshfs potrebbe cambiare la proprietà.

3 lug 2018 07:31:54