PDA

Visualizza versione completa : Apache su hosting (e locale): settaggi e dubbi permessi



Kirk78
22-04-12, 23: 37
Ciao a tutti!

Faccio questa discussione in abbinamento a - http://www.collectiontricks.it/forum/webmania/Ct4312-non-riesco-cambiare-dei-permessi-catella-hosting-condiviso.html - su Webmania, che mi serve per correggere un errore già fatto, per sapere come è possibile modificare un settaggio sull'hosting condiviso linux per evitare che un programma in php, o altro, non dia come proprietario di una cartella o file Apache.

Non so un .htaccess, un settaggio, una variabile con un programma php che posso avere senza avere la possibilità di andare a livello server, essendo un hosting condiviso linux e non un VPS.

Inoltre volevo provare, per evitare problemi, a mettere in locale, come suggerito giustamente da Asterix, Apache per provare a vedere che succede con un aggiornamento di wp all'ultima versione che è uscita il 20 aprile 2012. L'ho fatto parecchi anni fa quindi vi chiedo un modo più friendly per poterlo installare sul net windows 7.

Infine (che pizza questo Kirk78 :ghgh) come faccio a clonare esattamente la versione sull'hosting? La versione di Apache, del php e mySql, myphpadmin lo posso anche trovare (suggerimenti rapidi?) sul pannello di controllo. Non se addirittura mi possa convenire a mettere in modalità virtuale il tutto, ma non saprei cosa esattamente chiedere al providere.

Siete grandi comunque!

:bai

pierino_89
23-04-12, 01: 10
Ciao a tutti!

Faccio questa discussione in abbinamento a - http://www.collectiontricks.it/forum/webmania/Ct4312-non-riesco-cambiare-dei-permessi-catella-hosting-condiviso.html - su Webmania, che mi serve per correggere un errore già fatto, per sapere come è possibile modificare un settaggio sull'hosting condiviso linux per evitare che un programma in php, o altro, non dia come proprietario di una cartella o file Apache.

Ciao, prima di tutto devo dire che il tuo hosting è davvero strano perché in genere vengono utilizzati dei moduli apposta (tipo suphp) per far sì che php venga eseguito con il tuo utente e non con www-data, apache o quel che è. :ohoh
Senza quel modulo o un suo simile, php creerà i file e le cartelle secondo le regole di base di linux, ovvero: il file è di chi lo crea, il gruppo è quello predefinito dell'utente che lo ha creato, i permessi sono determinati dall'umask (che di predefinito è 022).
Umask 022 per farla breve significa che i file avranno permessi 644 e le cartelle 755.

L'unico modo per cambiare questo comportamento sarebbe cambiare l'utente che esegue apache, cosa che prima di tutto non è possibile nel tuo caso, e secondariamente è una cosa fondamentalmente sbagliata.
Se fossi in locale potresti cambiare l'umask a 002 (permessi 664 e 775) e aggiungerti al gruppo, ma naturalmente dato che non sei root non puoi farlo.



Non so un .htaccess, un settaggio, una variabile con un programma php che posso avere senza avere la possibilità di andare a livello server, essendo un hosting condiviso linux e non un VPS.

Per farla breve, io ti consiglierei di scrivere un miniscript php che cambi proprietario e permessi dei file che sono stati creati con proprietario diverso dal tuo utente, e lo lanci quando ti serve. Tanto, dato che viene lanciato da apache, ha i permessi necessari per fare ciò che deve.
PHP: chown - Manual (http://www.php.net/manual/en/function.chown.php)


Inoltre volevo provare, per evitare problemi, a mettere in locale, come suggerito giustamente da Asterix, Apache per provare a vedere che succede con un aggiornamento di wp all'ultima versione che è uscita il 20 aprile 2012. L'ho fatto parecchi anni fa quindi vi chiedo un modo più friendly per poterlo installare sul net windows 7.

Boh, so che ci sono cose tipo mamp o xampp, ma devi chiedere in sezione windows, io ho sempre installato apache + mod_php + mysql senza pormi particolari problemi (anche perché in ambiente linux è il metodo più ovvio).



Infine (che pizza questo Kirk78 :ghgh) come faccio a clonare esattamente la versione sull'hosting? La versione di Apache, del php e mySql, myphpadmin lo posso anche trovare (suggerimenti rapidi?) sul pannello di controllo. Non se addirittura mi possa convenire a mettere in modalità virtuale il tutto, ma non saprei cosa esattamente chiedere al providere.

Prima di tutto, che senso ha la pignoleria sulle versioni se parti già con due sistemi operativi diversi? :tong2
Comunque fondamentalmente è una perdita di tempo, perché anche installando versioni più recenti avresti la retrocompatibilità, e wordpress è scritto per funzionare su ambienti variegati chiedendo all'utente il minimo intervento possibile.
Io installerei php5.3 (dato che la 5.4 è discretamente recente, e quasi sicuramente non è installata in produzione in molti posti), apache2 l'ultima versione stabile, mysql 5.1 e phpmyadmin ultima versione stabile.
Copia il php.ini che hai sul sito ed eventualmente le direttive .htaccess se ne hai.

Buona fortuna! :eye

Kirk78
23-04-12, 01: 37
Che dire pierino_89 sei un grande! Intanto dico al provider questa cosa (tipo suphp) per capire il perché e provare il miniscript php che mi hai detto per cambiare almeno il propritario di quelle malefiche (per la sicurezza) cartelle e file.
In realtà è solo un plugin che mi ha fatto il danno, forse perché al suo interno c'era un settaggio particolare :boh
Tutte le cartelle e file sono con i permessi che hai citato, solo quelli caricati dal plugin avevano permessi superiori e proprietario Apache!

La mia pignoleria era perché non volevo avere una versione diversa (magari che protegge di più) in locale che poi quando lo metto on-line mi fa degli errori o differenti situazioni.

Eventualmente posso anche creare in virtuale un ambiente linux così avrei la stessa cosa che ho sull'hosting. Dovrei avere se non ricordo male un plesk come pannello di controllo quindi non so se potrei clonare il tutto in locale. Magari tramite un backup?

Ho creato io un .htaccess per alcune sicurezze e cambiamenti richieste dal wordpress del tipo

visto il .htaccess non è scrivibile scrivete xxxx sul file

Intanto vedo cosa posso fare da me e ti/vi faccio sapere. :thx

:bai

pierino_89
23-04-12, 02: 28
Che dire pierino_89 sei un grande! Intanto dico al provider questa cosa (tipo suphp) per capire il perché e provare il miniscript php che mi hai detto per cambiare almeno il propritario di quelle malefiche (per la sicurezza) cartelle e file.
In realtà è solo un plugin che mi ha fatto il danno, forse perché al suo interno c'era un settaggio particolare :boh
Tutte le cartelle e file sono con i permessi che hai citato, solo quelli caricati dal plugin avevano permessi superiori e proprietario Apache!
Ah, se te lo fa solo quel plugin allora probabilmente è bacato quello e basta, pensavo tutti i file creati da wordpress ti apparissero così.

In linea di massima ti cambia relativamente poco avere permessi anche indegni tipo 777, per il semplice motivo che l'unico modo per accedere a quei file sarebbe entrare con il tuo utente, e gli altri utenti sul server non potrebbero comunque arrivarci perché le cartelle superiori hanno permessi più restrittivi.

Esaminando bit a bit:
- lettura
Se non è leggibile da tutti, che ci sta a fare lì? Tutti i file lì sopra devono avere perlomeno il permesso di lettura per proprietario, gruppo e altri, altrimenti non possono essere mostrati.

- scrittura
Per quanto riguarda attacchi esterni, non credo tu abbia abilitato il metodo PUT o WebDAV quindi sostanzialmente al di fuori del server ogni file che pubblichi via webserver è come se fosse in sola lettura.

- esecuzione
Le cartelle devono avere il permesso di esecuzione per definizione, altrimenti non è possibile mostrarne il contenuto. I file NON dovrebbero averlo, se non lo necessitano (e difatti di predefinito non ce l'hanno mai). Nel tuo caso, nessun file necessita di quel permesso.
D'altra parte, il pericolo rappresentato è piuttosto minuto. Nel senso che comunque l'unico modo per lanciare un file eseguibile sarebbe via ssh, o con uno script php.
Il punto è che se è possibile caricare script php per un attaccante, meditare sui permessi è come disquisire del colore della serratura di una porta di cartapesta.

È buona cosa che tu voglia tenere in ordine i permessi, ma ricorda che sono l'ultimo anello della catena. :eye



La mia pignoleria era perché non volevo avere una versione diversa (magari che protegge di più) in locale che poi quando lo metto on-line mi fa degli errori o differenti situazioni.
È vero che nelle versioni successive vengono risolti bug e aggiunte nuove caratteristiche, ma tra minor versions (quando cambia solo la terza cifra) sostanzialmente non cambia niente.



Eventualmente posso anche creare in virtuale un ambiente linux così avrei la stessa cosa che ho sull'hosting. Dovrei avere se non ricordo male un plesk come pannello di controllo quindi non so se potrei clonare il tutto in locale. Magari tramite un backup?
Puoi solo esportare i tuoi dati, non quelli del server :tong2
Come ti ripeto, secondo me è assolutamente indifferente la piattaforma per il semplice fatto che se non funzionasse, dovresti tirare una padellata in testa a chi ha detto che dovrebbe funzionare :ghgh
Per il resto, ti consiglio di usare ciò che ti è più comodo e ciò che il buonsenso ti suggerisce. Ad esempio, phpmyadmin è un buon prodotto, ma in locale nessuno ti impedisce di usare mysql workbench o direttamente la sua shell (per citare due estremi).



Ho creato io un .htaccess per alcune sicurezze e cambiamenti richieste dal wordpress del tipo


Intanto vedo cosa posso fare da me e ti/vi faccio sapere. :thx

:bai
Suppongo sia per cose tipo mod_rewrite, se me lo incolli posso spiegarti cosa fa e quali moduli di apache ti servono, eventualmente. :hap

Kirk78
24-04-12, 10: 30
Ah, se te lo fa solo quel plugin allora probabilmente è bacato quello e basta, pensavo tutti i file creati da wordpress ti apparissero così.
Difatti è solo quella. Come detto nella discussione su webmania (risoluzione permessi alti) è il plugin "consigliato" direttamente da WP quando si fa "Importa" da pannello di controllo WP e, ahimé, le sotto cartelle (e file) sono quelle dell'upload e quindi la possibilità di caricare uno script php mascherato da immagine potrebbe essere reale, se non erro.


In linea di massima ti cambia relativamente poco avere permessi anche indegni tipo 777, per il semplice motivo che l'unico modo per accedere a quei file sarebbe entrare con il tuo utente
Immagino, però come detto le sotto cartelle sono quelle sotto upload :shock

I file NON dovrebbero averlo, se non lo necessitano (e difatti di predefinito non ce l'hanno mai). Nel tuo caso, nessun file necessita di quel permesso.
... e i file relativi che il plugin me li ha messi a 666, quindi lettura e scrittura a tutti, ma non esecuzione (rw-rw-rw). Quindi forse uno script potrebbe veramente non partire anche se mascherato: mi rassicuri?

Per quanto riguarda attacchi esterni, non credo tu abbia abilitato il metodo PUT o WebDAV
Non credo (io). Tranne .htacccess "locale" non ho abilitato alcun che. Non so se lo ha fatto il plugin.... Come faccio a verificare se sono stati abilitati qusti metodi, magari dalla confiugrazione "sopra" di me che non posso modificare?

È vero che nelle versioni successive vengono risolti bug e aggiunte nuove caratteristiche, ma tra minor versions (quando cambia solo la terza cifra) sostanzialmente non cambia niente.
Se parli di WP leggo che la differenza è proprio per la sicurezza, compreso quella dell'upload delle immagini: magari si sono accorti dopo un anno che c'era questo problema.... meglio tardi che mai! Solo che un upgrade di WP è abbastanza delicato. Ovviamente farò un backup del database tramite myphpadmin e anche dell'intero sito tramite ftp.

Suppongo sia per cose tipo mod_rewrite, se me lo incolli posso spiegarti cosa fa e quali moduli di apache ti servono
Grazie. Oltre alcuni mod_rewrite per la risoluzione della data (copiato direttamente dalle indicazioni di WP nei permalink) con il messaggio "queste sono le regole di mod_rewrite che si dovranno inserire nel file .htaccess manualmente" ovverosia i classici

Only registered members can view code.
la pagina di wp installato nella cartellab

Only registered members can view code.
e ho aggiunto la protezione del wp-config.php e .htaccess tramite la direttiva file

Only registered members can view code.
:bai

pierino_89
24-04-12, 14: 25
Difatti è solo quella. Come detto nella discussione su webmania (risoluzione permessi alti) è il plugin "consigliato" direttamente da WP quando si fa "Importa" da pannello di controllo WP e, ahimé, le sotto cartelle (e file) sono quelle dell'upload e quindi la possibilità di caricare uno script php mascherato da immagine potrebbe essere reale, se non erro.
"Ni". Nel senso che lo script dovrebbe essere abbastanza intelligente da non permetterti di caricare un file che non sia .jpg, .png o similare, sia via estensione che via mimetype.
In secondo luogo, se io prendo un file php e lo rinomino in png, apache lo servirà come immagine corrotta, senza interpretare il codice.



Immagino, però come detto le sotto cartelle sono quelle sotto upload :shock
Eh, ma se togli il permesso di scrittura alla cartella upload mi sa che poi wordpress non funzionerà mica tanto :tong2



... e i file relativi che il plugin me li ha messi a 666, quindi lettura e scrittura a tutti, ma non esecuzione (rw-rw-rw). Quindi forse uno script potrebbe veramente non partire anche se mascherato: mi rassicuri?

Non ti rassicuro :tong2 i file php quando vengono serviti vengono interpretati perché apache opera così, non perché abbiano il permesso di esecuzione.
La differenza tra uno script php con +x e uno con -x è che da shell il primo lo lanci con ./nomescript.php, il secondo con php -f nomescript.php
È comunque sensato che un file uploadato con owner diverso dal tuo abbia 666: in questo modo è scrivibile sia da wordpress che da te.

Diciamo: un attaccante NON deve riuscire a caricare un file php/perl/quel che è sul tuo server. Perlomeno, non con la sua estensione originale. Perché se ci riesce, non c'è permesso o aggeggio strano che tenga. :oo2



Non credo (io). Tranne .htacccess "locale" non ho abilitato alcun che. Non so se lo ha fatto il plugin.... Come faccio a verificare se sono stati abilitati qusti metodi, magari dalla confiugrazione "sopra" di me che non posso modificare?
Ad occhio e croce non puoi abilitarli tu direttamente, era un "tu" generico :bgg2
Cerca un client WebDav e prova, forse lo supporta persino direttamente il file manager (come succede per ftp). Non so dirti altro perché dolphin permette di accedere a qualunque cosa, quindi non saprei che programmi si possano usare.



Se parli di WP leggo che la differenza è proprio per la sicurezza, compreso quella dell'upload delle immagini: magari si sono accorti dopo un anno che c'era questo problema.... meglio tardi che mai! Solo che un upgrade di WP è abbastanza delicato. Ovviamente farò un backup del database tramite myphpadmin e anche dell'intero sito tramite ftp.
No, io parlavo del sottosistema, non dell'applicazione in sé. La versione per WP è importante, perché la struttura del database potrebbe cambiare.



Grazie. Oltre alcuni mod_rewrite per la risoluzione della data (copiato direttamente dalle indicazioni di WP nei permalink) con il messaggio "queste sono le regole di mod_rewrite che si dovranno inserire nel file .htaccess manualmente" ovverosia i classici

Only registered members can view code.
la pagina di wp installato nella cartellab

Only registered members can view code.
Giusto per capirci, hai capito cosa fa mod_rewrite di per sé? :hap Giusto per non essere ridondante.



e ho aggiunto la protezione del wp-config.php e .htaccess tramite la direttiva file

Only registered members can view code.
:bai
La direttiva "order" specifica in che ordine vengano elaborate le regole: se c'è prima "allow", i blocchi hanno la precedenza sulle eccezioni, altrimenti (prima "deny") viceversa.
"Deny from all" come è ovvio blocca l'accesso a tutti :oo2 al posto di "all" puoi specificare un indirizzo ip o una subnet, ad esempio. Oppure nomi utenti/gruppi.
"Satisfy all" indica che devono essere soddisfatte tutte le condizioni specificate. Ad esempio, se avessi "permetti l'accesso a utente 1" e "permetti l'accesso al gruppo 1", con "satisfy all" otterresti "permetti l'accesso all'utente 1 se appartiene al gruppo 1". Il suo opposto è "satisfy any", per cui basta una sola condizione ("permetti l'accesso all utente 1 oppure un utente qualsiasi del gruppo 1").
Nel tuo caso hai sola una regola, quindi "satisfy" non serve a una beneamata mazza :eye

Kirk78
24-04-12, 15: 30
Accidenti a me che sono andato ad impelagarmi in un CMS :ghgh, va bhè si studierà un po' di più. Poi con i tuoi consigli pratici è anche più semplice. Speriamo che chi ha fatto il plugin non abbia fatto macelli. Posso anche riprendere il programma php, ma allora mi faccio un plugin tutto mio. Ma poi il tempo si allunga.

Giusto per capirci, hai capito cosa fa mod_rewrite di per sé? Giusto per non essere ridondante.
Il mod_rewrite, per gli utenti che ci leggono e i visitatori, diciamo in parole poverissime, che è il modulo Apache che "trasforma" un link non reale (virtual) ad uno reale con le regole specificate: promosso :ghgh?

Ok ok tolgo il satisfy all :tong2 ... oppure lo lascio ma commentato se dovessi fare una 2° regola.


Eh, ma se togli il permesso di scrittura alla cartella upload mi sa che poi wordpress non funzionerà mica tanto
Ma wordpress ha tutte le cartelle, comprese quelle upload a 755 dove ho esportato i dati per poterli importare con quel malefico plugin, e funziona bene. Perché tu hai le cartelle upload e relative sottocartelle a 777?
Sul sito di wordpress dicono

No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory.
e quindi io mi stavo adeguando.
Curiosità c'è anche un PDF tra i file importati. Spero che WordPress di suo non permetta di caricare i php con l'estenzione .php (o derivato) ma solo quelli che no arrecano possibile danno.

Dal phpinfo vedo che è caricato il modulo mod_dav, non ho verificato se è attivo. C'erano un sacco di info su pluto ma non riesco più a raggiungere il sito :boh.

Si deve sempre studiare vero? :bai

pierino_89
24-04-12, 17: 20
Accidenti a me che sono andato ad impelagarmi in un CMS :ghgh, va bhè si studierà un po' di più. Poi con i tuoi consigli pratici è anche più semplice. Speriamo che chi ha fatto il plugin non abbia fatto macelli. Posso anche riprendere il programma php, ma allora mi faccio un plugin tutto mio. Ma poi il tempo si allunga.
Secondo me ti preoccupi troppo tu :tong2 comunque è una buona scusa per imparare qualcosa.



Il mod_rewrite, per gli utenti che ci leggono e i visitatori, diciamo in parole poverissime, che è il modulo Apache che "trasforma" un link non reale (virtual) ad uno reale con le regole specificate: promosso :ghgh?
Esatto... Si possono fare tante altre cose orride, ma l'utilità di base è quella: rendere gli url più intuitivi e migliorarne l'indicizzabilità per i motori di ricerca.


Ok ok tolgo il satisfy all :tong2 ... oppure lo lascio ma commentato se dovessi fare una 2° regola.Ma anche se lo lasci non cambia niente... è solo ridondante.



Ma wordpress ha tutte le cartelle, comprese quelle upload a 755 dove ho esportato i dati per poterli importare con quel malefico plugin, e funziona bene. Perché tu hai le cartelle upload e relative sottocartelle a 777?
No, ho 775, ma ho anche un settaggio diverso dal tuo. La questione è:
- il webserver gira con il tuo utente nei casi normali, con "apache" nei casi anomali (plugin)
- non puoi modificare l'appartenenza ai gruppi al tuo utente (quindi aggiungerlo al gruppo "apache" e mettere 775 non si può fare)
- se hai 755, o non hai accesso ai file tu, o non ha accesso ai file il plugin :eye
ecco perché finiamo su 777 (666 per i file) nella cartella di upload del plugin.



Sul sito di wordpress dicono

e quindi io mi stavo adeguando.
La buona educazione e la pratica purtroppo non sempre combaciano... Specie se ci sono bug che obbligano ad allentare la sicurezza :triste



Curiosità c'è anche un PDF tra i file importati. Spero che WordPress di suo non permetta di caricare i php con l'estenzione .php (o derivato) ma solo quelli che no arrecano possibile danno.
Prova a farlo, così ti togli il pensiero!



Dal phpinfo vedo che è caricato il modulo mod_dav, non ho verificato se è attivo. C'erano un sacco di info su pluto ma non riesco più a raggiungere il sito :boh.

Si deve sempre studiare vero? :bai
Ehehehehe, verissimo! :ghgh

Kirk78
24-04-12, 18: 31
Come hai ragione caro pierino_89 su pratica e buona educazione informatica! Più che studiare qualcosa di nuovo è riprendere ciò che già sapevo parecchi anni fa. Certo le tecnologie si evolvono e quindi devo comunque aggiornarmi.

- se hai 755, o non hai accesso ai file tu, o non ha accesso ai file il plugin
Se intendi il plugin di importazione l'ho disattivato. Per gli altri ti riferirò. Sono gli utenti che uploadano tramite WP. Io al massimo lo faccio dal pannello WP, anche se preferisco inserirli con l'ftp i file sull'hosting e quindi per default vanno con permessi 755 / 644.

Grazie dei tuoi preziosi consigli, e appena ri-attivo un utente provo ad uploadare un php, vedo che succede (non da ftp) e riferisco.

Per ora, fino a che non mi risponde il provider (suphp, che comunque secondo phpinfo il modulo non è caricato - mod_suphp), non posso mettere il risolto.

:bai

Kirk78
26-04-12, 20: 20
Ecco lo sapevo che neanche le prove posso fare! Adesso non posso neanche cambiare la sidebar e altre cosette... va bhè l'ho chiesto in Webmania (http://www.collectiontricks.it/forum/webmania/Ct4329-sidebar-non-modificabile.html) che dovrebbe essere la sezione giusta e speriamo di risolvere anche quella, che altrimenti posso solo studiare.

Comunque il provider mi ha inviato (non il tecnico ma una segretaria) un elenco di caratteristiche del server, anche se io avevo chiesto del suphp. Le uniche cose che potrebbero essere relative al PHP sono che il PHP Safe Mode è disattivo e il PHP Allow URL fopen è attivato...

Se ritrovo la segretaria amministrativa cosa potrei esattamente chiedergli (magari ha un file di testo che gli ha dato un tecnico) per sapere del suphp o similia per evitare il problema di questa discussione?

Grazie comunque! :bai

pierino_89
27-04-12, 13: 46
crea un file php con dentro:

Only registered members can view code.
e posta il risultato.
Safe mode e allow url fopen non sono relativi al problema.

Kirk78
27-04-12, 15: 09
Si il phpinfo l'avevo già messo un anno fa per vedere se vi sono aggiornamenti sul php (attualmente versione 5.3.10) o altro. I moduli caricati sono:

Only registered members can view code.
Configure Command:

Only registered members can view code.


Server API: Apache 2.0 Handler
Virtual Directory Support: disabled
Configuration File (php.ini) Path: /etc
Loaded Configuration File /etc/php.ini
Scan this dir for additional .ini files: /etc/php.d


Environment:

Only registered members can view code.

:bai

EDIT: sai dove vanno a finire tutti i settaggi di wp? Sul database immagino. Volevo fare una copia in locale.

pierino_89
28-04-12, 01: 49
Si il phpinfo l'avevo già messo un anno fa per vedere se vi sono aggiornamenti sul php (attualmente versione 5.3.10) o altro. I moduli caricati sono:

Only registered members can view code.

Ah, suppongo usi mod_suexec per cambiare utente.



EDIT: sai dove vanno a finire tutti i settaggi di wp? Sul database immagino. Volevo fare una copia in locale.
[/quote]
Un po' nel db e un po' in wp-qualcosa.php, ma dato che ti servirà tutta la cartella non me ne curerei troppo. Il nome file ti verrà in mente quando dovrai cambiare le impostazioni del db per fare le prove in locale.

Kirk78
28-04-12, 03: 53
Ah, suppongo usi mod_suexec per cambiare utente.
Quindi posso in qualche maniera risolvere la discussione, ovverosia la prevenzione di cambio di owner e di permessi?

Un po' nel db e un po' in wp-qualcosa.php
Non sai il wp-qualcosa.php? Perché quando faccio upload e download tramite ftp, a parte il locale non vorrei uploadare qualcosa di errato.
Grazie.

:bai

pierino_89
28-04-12, 04: 28
Quindi posso in qualche maniera risolvere la discussione, ovverosia la prevenzione di cambio di owner e di permessi?
In realtà no, sapere ciò non ti aiuta molto, fintanto che sembra essere il plugin la causa del problema. Non credo sia una cosa che tu possa risolvere in maniera definitiva finché non lo mettono a posto i suoi autori.



Non sai il wp-qualcosa.php? Perché quando faccio upload e download tramite ftp, a parte il locale non vorrei uploadare qualcosa di errato.
Grazie.

:bai
wp-config.php
comunque sarebbe davvero difficile caricarne un'altro per sbaglio, dato che di predefinito c'è solo l'esempio (che ha un nome diverso).

--- Post unito in modo automatico ---


Quindi posso in qualche maniera risolvere la discussione, ovverosia la prevenzione di cambio di owner e di permessi?
In realtà no, sapere ciò non ti aiuta molto, fintanto che sembra essere il plugin la causa del problema. Non credo sia una cosa che tu possa risolvere in maniera definitiva finché non lo mettono a posto i suoi autori.



Non sai il wp-qualcosa.php? Perché quando faccio upload e download tramite ftp, a parte il locale non vorrei uploadare qualcosa di errato.
Grazie.

:bai
wp-config.php
comunque sarebbe davvero difficile caricarne un'altro per sbaglio, dato che di predefinito c'è solo l'esempio (che ha un nome diverso).

Kirk78
28-04-12, 17: 11
In realtà no, sapere ciò non ti aiuta molto, fintanto che sembra essere il plugin la causa del problema. Non credo sia una cosa che tu possa risolvere in maniera definitiva finché non lo mettono a posto i suoi autori.
Ho capito. In buona sostanza questa discussione rimane irrisolta.... NON si può prevenire tramite qualche settaggio fatto da me.
E non so che chiedere specificatamente dei cambiamenti a livello più alto del mio per prevenirlo

Mi preoccupa se ce ne sono altri plugin che mi fanno questi cambi owner indesiderati... Linux è molto carino, però alle vole è troppo sicuro :ghgh
Peccato. Grazie comunque. :bai