Autorizzazioni di file corretto per WordPress

Ho dato un’occhiata su qui ma non ho trovato dettagli sul miglior file di autorizzazioni. Ho anche dato un’occhiata ad alcuni di WordPress forma alle domande di sopra anche qui ma nessuno che suggerisce 777, ovviamente, ha bisogno di un po ‘ di lezione in sicurezza.

In breve la mia domanda è questa. Quali autorizzazioni devo avere per i seguenti:

  1. cartella principale la conservazione di tutti i WordPress contenuto
  2. wp-admin
  3. wp-content
  4. wp-includes

e quindi tutti i file in ciascuna di queste cartelle?

  • Fondamentalmente, solo upload di WordPress cartella deve essere 777 ma sarebbe una grave minaccia per la sicurezza. Se si utilizza un server con Suphp abilitato, non c’è bisogno di modificare le autorizzazioni, manualmente.
  • Io voto per chiudere questa domanda off-topic, perché è off-topic per il tag wiki estratto: “Off-topic di domande sono quelle sul tema dello sviluppo, amministrazione di WordPress, migliori pratiche di gestione, la configurazione del server, ecc”

 

15 Replies
  1. 486

    Quando l’installazione di WP è (webserver) potrebbe essere necessario l’accesso in scrittura ai file. Così i diritti di accesso possono avere bisogno di essere sciolto.

    chown www-data:www-data  -R * # Let Apache be owner
    find . -type d -exec chmod 755 {} \;  # Change directory permissions rwxr-xr-x
    find . -type f -exec chmod 644 {} \;  # Change file permissions rw-r--r--

    Dopo l’installazione si dovrebbe serrare i diritti di accesso, secondo Indurimento WordPress tutti i file tranne per wp-content deve essere modificabile tramite il tuo account utente solo. wp-content deve essere scrivibile da www-data troppo.

    chown <username>:<username>  -R * # Let your useraccount be owner
    chown www-data:www-data wp-content # Let apache be owner of wp-content

    Forse si desidera modificare il contenuto in wp-content seguito. In questo caso si potrebbe

    • modificare temporaneamente all’utente di www-data con su,
    • dare wp-content group accesso in scrittura 775 e unirsi al gruppo www-data o
    • dare il vostro utente i diritti di accesso alla cartella utilizzando Acl.

    Qualunque cosa tu faccia, assicurarsi che i file hanno rw autorizzazioni per www-data.

    • Plausibile, se wp deve solo wpcontent. Avete tutti i riferimenti a substabtiate la tua tesi? Questo è COSÌ non solo chit-chat. Fino ad ora il tuo commento è un semplice sfogo.
    • Kornel dà una tale autorevole link qui sotto. Vedi anche codex.wordpress.org/Changing_File_Permissions, Apache doc httpd.apache.org/docs/2.2/misc/security_tips.html, e praticamente qualsiasi ricerca su google l’argomento. Ma nel caso generale, in caso di dubbio, non danno l’accesso in scrittura (e certamente non di proprietà) e allentare, caso per caso, non il contrario (principio del minimo privilegio che stai violando qui).
    • Sono d’accordo per l’approccio qui. Un set di autorizzazioni per “installazione/aggiornamento” e “hardened” permesso di set sembra essere il modo migliore per garantire sia la facilità di aggiornamento, fornendo la sicurezza in una forma accettabile.
    • Perché c’è una funzionalità di aggiornamento automatico, se non anche di lavoro senza modificare i permessi??
    • Vedo alcuni file PHP sotto wp-content, sono questi davvero dovrebbe essere scrivibile da www-data??? Che suoni davvero del tutto sicuro a tutti.
    • Soluzione perfetta!
    • Se si desidera WP per essere in grado di auto-aggiornamento, allora sì. Se vuoi più stretto autorizzazioni che è possibile impostare, ma devi aggiornare il tutto manualmente via ftp.
    • Penso che sia importante per impostare l’accesso in sola lettura a wp-config.php e possibilmente anche .htaccess file. chmod 444 wp-config.php e possibilmente anche chmod 444 .htaccess
    • Una breve nota: sul mio server, la configurazione di 755 autorizzazioni su una dir ammessi elenco di directory per il mondo. È necessario essere prudenti. Per evitare elenco di directory, è possibile utilizzare 751, invece.
    • Questa soluzione impedisce wordpress installazione automatica di aggiornamenti di sicurezza’. È necessario eseguire manualmente la procedura di cui sopra per ogni minore, wordpress, aggiornamento.
    • perfetto 🙂 grazie
    • per l’utente di mac os gruppo è _www invece di www-data
    • su www-data non funziona, non si può cambiare ruolo a questo utente di sistema dal design.
    • Questa non è una configurazione sicura. Impostazione delle autorizzazioni di lettura di questi file non ha alcun effetto quando l’utente apache, inoltre, possiede il file! NON UTILIZZARE. Fare riferimento a codex.wordpress.org/Changing_File_Permissions
    • Alcuni servizi di hosting, server viene eseguito con l’account del proprietario credenziali e non c’è modo intorno ad esso. Senza “www-data”, non “di nessuno”, non di “apache”, per il solo utente:utente. Se questo è il tuo caso, ti consigliamo di chmod di tutti i file al 0444 e cartelle di 0555 (sì, eliminando proprio i permessi di scrittura), salvo che per l’upload di una cartella, e solo sbloccarli quando si esegue un aggiornamento.
    • che cosa circa wp-content/uploads cartella? dopo serrare i diritti di accesso non può caricare l’immagine dal pannello di amministrazione.

  2. 58

    Dà il pieno accesso a tutti i file di wp per www-data utente (che in questo caso è l’utente del web server) può essere pericoloso.
    Quindi, piuttosto che fare NON fare questo:

    chown www-data:www-data -R *

    Può essere utile, tuttavia, nel momento in cui si esegue l’installazione o l’aggiornamento di WordPress e i suoi plugin. Ma quando è finito, non è più una buona idea per mantenere wp file di proprietà di un server web.

    Che permette, in pratica, il server web per inserire o sovrascrivere qualsiasi file nel tuo sito web.
    Questo significa che c’è una possibilità di prendere in consegna il tuo sito, se qualcuno riesce a utilizzare il server web (o una falla di sicurezza in alcuni .script php) a mettere alcuni file nel tuo sito web.

    Proteggere il vostro sito contro un attacco del genere si dovrebbe seguenti:

    Tutti i file devono essere di proprietà dell’account utente, e deve essere scrivibile
    da voi. Qualsiasi file che deve accedere in scrittura da WordPress dovrebbe essere
    scrivibile dal server web, se il vostro hosting impostare lo richiede, che
    può significare questi file devono essere di proprietà dell’account utente utilizzato
    il processo del server web.

    /

    Il root di WordPress directory, tutti i file devono essere scrivibile solo dal tuo account utente, ad eccezione di .htaccess se si vuole WordPress
    generare automaticamente le regole di riscrittura per voi.

    /wp-admin/

    L’area di amministrazione di WordPress: tutti i file devono essere scrivibile solo dal tuo account utente.

    /wp-includes/

    La maggior parte delle WordPress logica di applicazione: tutti i file devono essere scrivibile solo dal tuo account utente.

    /wp-content/

    Forniti dall’utente contenuto: destinato a essere scrivibile dal vostro account utente e il web server di processo.

    Entro /wp-content/ troverete:

    /wp-content/themes/

    File del tema. Se si desidera utilizzare il built-in editor del tema, tutti i file devono essere scrivibile dal server web di processo. Se non
    desidera utilizzare il built-in editor del tema, tutti i file possono essere scrivibile solo
    dal vostro account utente.

    /wp-content/plugins/

    Plugin file: tutti i file devono essere scrivibile solo dal tuo account utente.

    Altre directory che possono essere presenti con /wp-content/ dovrebbe essere
    documentato da qualsiasi plugin o un tema richiede. Le autorizzazioni possono
    variare.

    Fonte e ulteriori informazioni: http://codex.wordpress.org/Hardening_WordPress

    • dal tuo account utente. significa che l’utente che esegue lo script php sul sito (Normalmente l’utente di apache) ?
    • No, l’utente apache è quella che lui definisce “processo del server web”. Account utente è il tuo utente Linux (ssh, ftp, etc.)
    • In questa risposta, e accettate la risposta deve essere l’utente (non www-data) essere parte del gruppo www-data?
    • No, il punto è tutto qui.
    • Il problema che ho esperienza in qualsiasi momento faccio il mio SSH “utente” il proprietario di /wp-content/plugins/ WordPress diventa completamente unfunctional dall’interno admin, con il costante FTP, pop-up di routine o le autorizzazioni di errori. Non può aggiungere, né di aggiornamento del plugin. Solo quando faccio www-data, il proprietario di wp-content, l’amministrazione di WordPress plugin funzionalità. (Esempio: sudo chown www-data:www-data -R /var/www/html/wp-content/)
    • Si potrebbe (temporaneamente) definire FTP_USER, FTP_PASS, FTP_HOST in wp-config.php e WP sarà smettere di chiedere.
    • Mi piacerebbe riferimento la risposta che ho fornito qui come un’aggiunta a questo: stackoverflow.com/questions/17922644/… – sembra che i file di sistema di controlli di WordPress si impegna, durante il caricamento dei plug-in (per esempio) non è pendente verso avendo lo stesso principio, proprio i file dell’applicazione, & eseguire il processo php. Pensieri?

  3. 25

    Per coloro che hanno il loro wordpress cartella principale sotto la loro cartella home:

    ** Ubuntu/apache

    1. Aggiungere il proprio utente al gruppo www-data:

    Di CREDITO La concessione di permessi di scrittura al gruppo www-data

    Che si desidera chiamare usermod per l’utente. In modo che sarebbe:

    sudo usermod -aG www-data yourUserName

    ** Supponendo www-data esiste un gruppo di

    1. Controllare il tuo utente è in www-data gruppo:

      groups yourUserName

    Si dovrebbe ottenere qualcosa di simile:

    youUserName : youUserGroupName www-data

    ** youUserGroupName è di solito simile per il nome utente

    1. Cambiare ricorsivamente proprietà di gruppo wp-content cartella di mantenere la vostra proprietà utente

      chown yourUserName:www-data -R youWebSiteFolder/wp-content/*

    2. Cambiare la directory di youWebSiteFolder/wp-content/

      cd youWebSiteFolder/wp-content

    3. Cambiare ricorsivamente i permessi del gruppo di cartelle e sotto-cartelle per abilitare i permessi di scrittura:

      find . -type d -exec chmod -R 775 {} \;

    ** modalità di ” /home/tuonomeutente/youWebSiteFolder/wp-content/’ cambiato da 0755 (rwxr-xr-x) 0775 (rwxrwxr-x)

    1. Cambiare ricorsivamente i permessi del gruppo di file e sub-file per abilitare i permessi di scrittura:

      find . -type f -exec chmod -R 664 {} \;

    Il risultato dovrebbe essere qualcosa di simile:

    WAS:
    -rw-r--r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html
    CHANGED TO:
    -rw-rw-r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html

    Equivalente a:

    chmod -R ug+rw nomecartella

    Autorizzazioni sarà come 664 file o 775 per le directory.

    P. s. se qualcuno rileva un errore di 'could not create directory' durante l’aggiornamento di un plugin, fare:

    [email protected]:~/domainame.com$ sudo chown username:www-data -R wp-content

    quando siete alla root del tuo dominio.

    Supponendo che: wp-config.php ha

    Le credenziali FTP LocalHost

    define('FS_METHOD','direct');

    • -1. Ti do NON voglio www-data di accedere in scrittura al file di wordpress, tranne che in wp-content.
    • 775 in wp-content aiuta. Con 644 per i file, 755 per le cartelle e chown utente:www-data, sono stato a volte ancora avendo problemi con la media di caricamento, aggiornamento del plug-in, etc. 775 permette wp-content per essere alterato da www-data:www-data, che risolve il problema.
    • Rimuovere l’-R da trovare/comando chmod, come è lento e inutile.
  4. 20

    Meglio leggere wordpress, documentazione su questa https://codex.wordpress.org/Changing_File_Permissions

    • Tutti i file devono essere di proprietà dell’utente effettivo del conto, non l’account utente utilizzato per il processo httpd
    • La proprietà del gruppo è irrilevante, a meno di specifiche esigenze del gruppo per il web-server del processo di autorizzazioni di controllo. Questo non è solitamente il caso.
    • Tutte le directory devono essere 755 750.
    • Tutti i file devono essere 644 o 640. Eccezione: wp-config.php dovrebbe essere 440 o 400 per impedire ad altri utenti sul server da lettura.
    • Cartelle dovrebbe mai essere dato 777, anche caricare le directory. Dal momento che il processo php è in esecuzione come il proprietario del file, ottiene i titolari di autorizzazioni e può scrivere anche un 755 directory.
    • Non so perché hai giù votato: è quasi come se la gente vuole la risposta in alto per essere come lasciare l’installazione insicuro!
    • Il Link non è aggiornato. nuovo qui: wordpress.org/support/article/changing-file-permissions E grazie per essere stato l’unico riferimento reale docs!
  5. 15

    Ho impostato le autorizzazioni per:

        # Set all files and directories user and group to wp-user
        chown wp-user:wp-user -R *
    
        # Set uploads folder user and group to www-data
        chown www-data:www-data -R wp-content/uploads/
    
        # Set all directories permissions to 755
        find . -type d -exec chmod 755 {} \;
    
        # Set all files permissions to 644
        find . -type f -exec chmod 644 {} \;

    Nel mio caso ho creato un utente specifico per WordPress, che è diverso da apache di default utente che impediscono l’accesso dal web per i file di proprietà dell’utente.

    Poi dà il permesso all’utente di apache per gestire la cartella per l’upload e, infine, impostare abbastanza sicuro autorizzazioni di file e cartelle.

    A CURA

    Se si utilizza W3C Cache Totale si dovrebbe fare il prossimo anche:

    rm -rf wp-content/cache/config
    rm -rf wp-content/cache/object
    rm -rf wp-content/cache/db
    rm -rf wp-content/cache/minify
    rm -rf wp-content/cache/page_enhanced

    Poi funzionerà!

    A CURA

    Dopo un po ‘ lo sviluppo di siti WordPress mi consiglia di diverse autorizzazioni file per l’ambiente:

    In produzione, non vorrei dare l’accesso agli utenti di modificare il filesystem, ho solo consentire loro di caricare le risorse e consentire l’accesso ad alcuni plugin cartelle specifiche per fare i backup, etc. Ma la gestione di progetti in Git e l’utilizzo di distribuire le chiavi sul server, per cui non è bene aggiornare il plugin sulla messa in scena e non di produzione. Lascio qui la produzione l’installazione di file:

    # Set uploads folder user and group to www-data
    chown www-data:www-data -R wp-content/uploads/

    www-data:www-data = apache o nginx utente e di gruppo

    Scenografie, condividere la stessa casa di produzione di autorizzazioni di come dovrebbe essere un clone di esso.

    Infine, ambiente di sviluppo di avere accesso ad aggiornare i plugin, traduzioni, tutto…

    # Set uploads folder user and group to www-data
    chown www-data:www-data -R wp-content/
    
    # Set uploads folder user and group to www-data
    chown your-user:root-group -R wp-content/themes
    
    # Set uploads folder user and group to www-data
    chown your-user:root-group -R wp-content/plugins/your-plugin

    www-data:www-data = apache o nginx utente e di gruppo
    tuo-utente:root-group = corrente dell’utente e gruppo root

    Queste autorizzazioni darà accesso a svilupparsi sotto themes e your-plugin cartella senza chiedere il permesso. Il resto del contenuto, sarà di proprietà dell’Apache o Nginx utente per consentire WP per gestire il filesystem.

    Prima di creare un repo git prima di eseguire questi comandi:

    # Set all directories permissions to 755
    find . -type d -exec chmod 755 {} \;
    
    # Set all files permissions to 644
    find . -type f -exec chmod 644 {} \;
    • Nooo! Mai fare un 777. Per favore, non consiglio questo (nuovo) persone che leggono questo.
    • NESSUN file o cartelle devono essere di proprietà del http processo – questa è una grande lacuna di sicurezza. Se un utente malintenzionato ha trovato un exploit in un plugin o un tema o wordpress si potevano caricare il codice che può essere eseguito da apache e di ottenere accesso – ho visto di prima mano 🙁
  6. 10

    Autorizzazioni corrette per il file 644
    Correggere le autorizzazioni per la cartella 755

    Per modificare le autorizzazioni , utilizzare il terminale e seguenti comandi.

    find foldername -type d -exec chmod 755 {} \;
    find foldername -type f -exec chmod 644 {} \;

    755 per le cartelle e 644 per i file.

    • e 640 per wp-config.php.Ma, purtroppo, è necessario modificare l’upload&plugins&temi cartelle i permessi a 775 e se volete aggiornare il vostro wordpress quindi è necessario modificare tutte le cartelle per 775.In questa sezione si dispone di autorizzazioni di pop-up errori durante l’aggiornamento/modifica di plugin,temi e caricamento dei supporti.
  7. 8

    Veramente dipende dal plugin si prevede di utilizzare come alcuni plugin modificare il documento principale di wordpress. ma in generale mi consiglia qualcosa di simile a questo per wordpress directory.

    Questo assegnerà il “root” (o qualunque sia l’utente che si sta utilizzando) come l’utente in ogni singolo file/cartella, R indica ricorsiva, quindi non solo non si ferma alla cartella “html”. se non si utilizza R, quindi è applicabile solo per il “html” directory.

    sudo chown -R root:www-data /var/www/html  

    Questo imposterà il proprietario/gruppo di “wp-content” a “www-data” e, quindi, consentire il web server per installare il plugin attraverso il pannello di amministrazione.

    chown -R www-data:www-data /var/www/html/wp-content

    Questo imposterà l’autorizzazione di ogni singolo file nella cartella “html” (Compresi i file nelle sottodirectory) a 644, così la gente di fuori non può eseguire qualsiasi tipo di file, modificare qualsiasi file, non sarà possibile eseguire qualsiasi tipo di file, modificare qualsiasi tipo di file e solo l’utente ha la facoltà di modificare/leggere i file, ma ancora anche l’utente non può eseguire qualsiasi file. Questo è importante perché impedisce qualsiasi tipo di esecuzione nella cartella “html”, anche perché il proprietario della cartella html e tutte le altre cartelle, ad eccezione della wp-content cartella “root” (o utente), il www-data non è possibile modificare qualsiasi tipo di file al di fuori di wp-content cartella, quindi anche se c’è qualche problema di vulnerabilità del web server, e se qualcuno accede al sito unauthorizedly, essi non possono eliminare il sito principale, eccetto i plugin.

    sudo find /var/www/html -type f -exec chmod 644 {} +

    Ciò limita il permesso di accedere a “wp-config.php” per utente/gruppo con rw-r—– queste autorizzazioni.

    chmod 640 /var/www/html/wp-config.php

    E se un plugin o un aggiornamento si lamentava riesco ad aggiornare, quindi l’accesso a SSH e utilizzare questo comando, e di concedere l’autorizzazione temporanea per “www-data” (web server) per aggiornare/installare attraverso il pannello di amministrazione, e poi tornare alla “radice” o il vostro utente una volta completato.

    chown -R www-data /var/www/html

    E in Nginx (stessa procedura per il apache)per proteggere il wp-admin cartella da accessi non autorizzati, l’accesso e la tastatura. apache2-utils è richiesto per crittografare la password, anche se si dispone di nginx installato, omettere c se si prevede di aggiungere più utenti allo stesso file.

    sudo apt-get install apache2-utils
    sudo htpasswd -c /etc/nginx/.htpasswd userName

    Ora di visitare questa località

    /etc/nginx/sites-available/

    Utilizzare questi codici per proteggere “wp-admin” una cartella con una password, ora chiederà la password o il nome utente, se si è tentato di accedere al “wp-admin”. avviso, qui si utilizza “.htpasswd” il file che contiene la password crittografata.

    location ^~ /wp-admin {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        index  index.php index.html index.htm;
    }

    Ora riavviare il nginx.

    sudo /etc/init.d/nginx restart
    • Usando l’utente root non è raccomandato.potrebbe essere più pericoloso Basta creare un nuovo utente n aggiungerlo al gruppo sudo
    • Io non l’avvocato qui per usare il root. Ho usato la radice come un esempio. è possibile utilizzare qualsiasi cosa per nome invece di usare il root.
  8. 7

    Penso che le seguenti regole sono consigliati per un default di wordpress sito:

    • Per le cartelle all’interno di wp-content, set 0755 autorizzazioni:

      chmod -R 0755 plugin

      chmod -R 0755 upload

      chmod -R 0755 aggiornamento

    • Lasciare utente apache essere il proprietario per il sopra la directory wp-content:

      chown apache upload

      chown apache aggiornamento

      chown apache plugin

    • È anche possibile, in modo ricorsivo, impostare le autorizzazioni per la directory, come: chown -R apache upload. E, se necessario, si può anche dare la proprietà del gruppo di apache: chgrp apache upload
  9. 2

    Comandi:

    chown www-data:www-data -R *
    find . -type d -exec chmod 755 {} \;
    find . -type f -exec chmod 644 {} \;

    Dove ftp-user è l’utente che si utilizza per caricare i file

    chown -R ftp-user:www-data wp-content
    chmod -R 775 wp-content
    • dovrebbe essere chown utente:www-data, altrimenti non è possibile modificare i file
    • È possibile utilizzare $(whoami) invece di ftp-user. Per impostazione predefinita, il vostro utente corrente (non root) è il tuo utente FTP se si utilizza un proprio server (locale, vps, ecc)
  10. 2

    Assolutamente assicurarsi che il vostro sito è sicuro e uso corretto delle autorizzazioni per le cartelle, utilizzare un plug-in di protezione come questi:

    https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/

    https://en-ca.wordpress.org/plugins/wordfence/

    Questi plugin effettuerà una scansione del tuo WordPress installazione e la notifica di eventuali problemi potenziali. Questi saranno anche segnalare qualsiasi insicuro autorizzazioni della cartella. In aggiunta a ciò, questi plugin si consiglia di quali autorizzazioni devono essere assegnati alle cartelle.

  11. 2
    chown -Rv www-data:www-data
    chmod -Rv 0755 wp-includes
    chmod -Rv 0755 wp-admin/js
    chmod -Rv 0755 wp-content/themes
    chmod -Rv 0755 wp-content/plugins
    chmod -Rv 0755 wp-admin
    chmod -Rv 0755 wp-content
    chmod -v 0644 wp-config.php
    chmod -v 0644 wp-admin/index.php
    chmod -v 0644 .htaccess
  12. 1

    Non posso dirvi se o non questo è corretto, ma io sto usando un Bitnami immagine su Google Compute App Engine. Non ho problemi con i plugin e migrazione, e dopo ulteriori rovinare le cose da chmod ing autorizzazioni, ho trovato queste tre righe che ha risolto tutti i miei problemi. Non so se è il modo corretto, ma ha funzionato per me.

    sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/
    sudo find /opt/bitnami/apps/wordpress/htdocs/ -type f -exec chmod 664 {} \;
    sudo find /opt/bitnami/apps/wordpress/htdocs/ -type d -exec chmod 775 {} \;
  13. 1

    Definire in wp_config file.

    /var/www/html/Your-Project-File/wp-config.php

    define( 'FS_METHOD', 'direct' );

    chown – cambia la proprietà di file/cartelle. Ie. proprietario del file/dir modifiche a quello specificato, ma non modificare le autorizzazioni.

    sudo chown -R www-data:www-data /var/www
  14. 0

    Sulla base di tutte le lettura e agonizzante sui miei siti, e dopo essere stati violati sono venuto con la lista di cui sopra che include le autorizzazioni di sicurezza plugin per WordPress chiamato Wordfence. (Non legati)

    Nel nostro esempio, la document root di wordpress è
    /var/www/html/esempio.com/public_html

    Aprire i permessi in modo che www-data è possibile scrivere la radice del documento come segue:

    cd /var/www/html/example.com
    sudo chown -R www-data:www-data public_html/

    Ora dal pannello di controllo del sito, come amministratore è possibile eseguire gli aggiornamenti.

    Sito sicuro dopo gli Aggiornamenti sono finiti seguendo questi passaggi:

    sudo chown -R wp-user:wp-user public_html/

    Il comando di cui sopra cambia i permessi di tutto ciò che nell’installazione di wordpress per wordpress utente FTP.

    cd public_html/wp-content
    sudo chown -R www-data:wp-user wflogs
    sudo chown -R www-data:wp-user uploads

    Il comando di cui sopra garantisce che il plug-in di protezione Wordfence ha accesso ai suoi registri. La directory di upload è anche scrivibile da www-data.

    cd plugins
    sudo chown -R www-data:wp-user wordfence/

    Il comando di cui sopra, inoltre, garantisce che il plug-in di protezione è necessario leggere l’accesso in scrittura per il suo corretto funzionamento.

    Directory e File di Autorizzazioni

    # Set all directories permissions to 755
    find . -type d -exec chmod 755 {} \;
    
    # Set all files permissions to 644
    find . -type f -exec chmod 644 {} \;

    Impostare le autorizzazioni per wp-config.php a 640, in modo che solo wp-l’utente può leggere questo file e nessun altro. Autorizzazioni di 440 non ha funzionato per me con sopra la proprietà del file.

    sudo chmod 640 wp-config.php

    WordPress aggiornamenti automatici tramite SSH stessero lavorando bene con PHP5, ma ha rotto con PHP7.0 a causa di problemi con php7.0-ssh2 bundeld con Ubuntu 16.04 e non riuscivo a trovare il modo di installare la versione giusta e farlo funzionare. Fortunatamente molto affidabile plugin chiamato ssh-sftp-updater-supporto (gratuito) fa gli aggiornamenti automatici tramite SFTP possibile senza necessità di libssh2. Pertanto, le suddette autorizzazioni non devono mai essere allentato, tranne in rari casi come necessario.

Lascia un commento