[RISOLTO]Devo dare i permessi di scrittura a tutte le cartelle?

[ritz2]

Dopo aver provato tutto in locale ho installato in rete.
Alla prima installazione di un componente (template JA_Purity_II ) sono iniziati i guai.
Ho controllato la cartella temp ed ho visto che non era scrivibile, l'ho resa scrivibile, però l'installazione si è fermata di nuovo con questa scritta "* JFolder::create: Impossibile creare la cartella* Unable to write entry"
Come devo comportarmi, devo sbloccare tutte le cartelle?
Comprometto la sicurezza?

[mau_develop]

Comprometto la sicurezza?
--------------------------
quasi sicuramente si

Come devo comportarmi, devo sbloccare tutte le cartelle?

se sei su server win... puoi piangere, è già un buon inizio,

altrimenti prova semplicemente a controllare di aver messo le path giuste a tmp e cache nel file configuration.php.

I permessi delle cartelle non vanno toccati (quelli dei file nemmeno)

M.

[santograz]

Beh,
in amministrazione->info->Permessi cartelle, ti dice quali cartelle devono essere scrivibili (777)...

[ritz2]

Beh,
in amministrazione->info->Permessi cartelle, ti dice quali cartelle devono essere scrivibili (777)...

In localhost, sono tutte scrivibili (non avevo toccato nulla) adesso me le trovo tutte non scrivibili, non ho toccato nulla ha fatto tutto joomla.
Il server è Unix, il configuration.php me lo ha proposto joomla, l'ho copiato messo nella root ed il sito ha funzionato perfettamente.
Ho pensato di mettere il sito off-line dare i permessi a tutte le cartelle, lavorarci, toglierle di nuovo i permessi e mettere on-line (anche se mi pare strano  )

[santograz]

Oggi dev'essere una sorta di fetsa della paura...

Innanzitutto, quando trasferisci delle cartelle, da un server all'altro, non trasferisci anche i permessi. Chi fa il file transfer è un server (ftp) e fa quello che vuole lui.

Cambiando i permessi come indicato dal test di joomla, non comprometti la sicurezza del sito, quelle cartelle VANNO lasciate a 777, altrimenti avrai sempre probemi

[frascan]

Piccola nota di precisazione: i permessi a 777 sono da evitare se non strettamente necessario. Prima di pasticciare con i permessi vi invito a leggere un ottimo articolo comparso qualche settimana fa su joomla.it:

http://www.joomla.it/articoli-della-community/4200-i-permessi-linux-e-lhosting.html

da li si evince chiaramente che i problemi di scrittura di files e cartelle non dipendono soltanto dal chmod (permessi) su files e cartelle ma anche da altri fattori.

[santograz]

Carissimo frascan,
hai assolutamente ragione, i permessi a 777 sono pericolosi, siccome a tutti gli utenti di quel server di scrivere in quelle cartelle.
Tuttavia, il server sa riconoscere gli utenti, per cui il pericolo viene proprio dal server stesso, che a 777 può scrivere nelle predette cartelle (ok, se la cartella è /images farebbe solo il suo lavoro).

Ma se settiamo il server in maniera che funzionino i permessi a 755, vuol dire che apache e TUTTI gli user del server girano sotto lo stesso gruppo, il chè non cambia molto la situazione: se qualcuno riesce ad impersonare uno user, "gira" tranquillamente per tutto il server con i permessi di gruppo di apache (lo stesso apache continuerebbe comunque a poter scrivere in quelle cartelle).

L'articolo è bello, ma dopo averlo letto non mi sembra di saperne molto di più...

Comunque, senza permessi di scrittura, non riesci neanche ad aggiungere un articolo a joomla, se questo articolo dovesse, per esempio, contenere un'immagine caricata in una cartella di /images/stories/ direttamente dall'editor.

[mau_develop]

probabilmente perchè non hai afferrato dei passaggi...

se settiamo il server in maniera che funzionino i permessi a 755, vuol dire che apache e TUTTI gli user del server girano sotto lo stesso gruppo

come fai a dire qs?

5 vuol dire che puoi leggere il file e sei user, owner, cioè 7 non puoi diventarlo mai se non attraverso gli script che girano sul server.
Questa cosa è dimostrata dal fatto che se in locale setti male le ownership, tutte le volte che installi qualcosa il proprietario è www-data.

Su un server tu devi essere sempre owner o group, a quel punto a seconda di cosa tu sia devi avere permessi 7

M.

[santograz]

Hai ragione, mi riferivo ai permessi 775 ed ho scritto 755...

A 755 solo l'owner può scrivere nella cartella.... Il concetto comunque non cambia: a 775 user e apache dovrebbero essere nello stesso gruppo, se vogliamo che gli script php aprano le cartelle e ci scrivano...

[mmleoni]

@ritz2

ciao,
proprio sicuro che il percorso in $tmp_path sia corretto? ricorda che deve essere aggiornato ogni volta che si sposta il sito: verifica perché 9 su 10 il problema è qui.

i permessi non dovrebbero mai essere toccati (di solito si interviene solo per renderli più restrittivi), salvo errori del provider, che non puoi correggere tu, l'ftp scrive con i permessi giusti perché il sito funzioni.

prova a caricare delle immagini con il media manager e vedi se funziona, in caso contrario rivolgiti all'assistenza.

ciao,
marco

[santograz]

I permessi non vanno mai toccati?

Ragazzi, leggiamoci un po' di manuali prima di sviare in questo modo chi chiede aiuto...

E' vero, l'FTP scrive con i permessi giusti, perchè è di proprietà dell'owner, ma apache no: per questo alcune cartelle devono essere aperte.

Last but not least, caro ritz, se non sai neanche come settare i permessi (non è un peccato, per la carità, ma sono le basi di joomla), ti vuoi già occupare di sicurezza?

[mmleoni]

Ragazzi, leggiamoci un po' di manuali prima di sviare in questo modo chi chiede aiuto...

E' vero, l'FTP scrive con i permessi giusti, perchè è di proprietà dell'owner, ma apache no: per questo alcune cartelle devono essere aperte.

non sono assolutamente d'accordo, con nessuno dei provider che utilizzo (e di sicuro vi sono i tre più grandi italiani) ho dovuto fare una cosa del genere, se non per errori del provider, prontamente corretti dopo la segnalazione. quanto meno farei una cosa del genere sui servers che amministro...

comunque non si possono fare osservazioni a valenza generale relativamente alla ownership del file e/o ad uid con cui girano i vari daemon senza sapere come è configurato il server, tanto meno vanno dati ad utenti alle prime armi suggerimenti che possono creare falle di sicurezza.

777 non deve esistere come configurazione di produzione.

poi ognuno resta della sua idea

ciao,
marco

[santograz]

Vuoi dire che lavori su di un server non locale con i permessi della temp e della cache a 644 o anche a 755? Interessante.

Comunque, hai ragione tu, ognuno con la propria idea, ma diamo consigli su Joomla, e se quelli che del Team Joomla, che sono gente sveglia, dicono che alcune cartelle devono essere scrivibili e perdono addirittura il tempo di inserire un test nel CMS, penso dobbiamo rispettare il loro lavoro.

Avere le proprie idee è un diritto, divulgarle come legge è una cosa de fare con responsabilità.

[mau_develop]

Vuoi dire che lavori su di un server non locale con i permessi della temp e della cache a 644 o anche a 755? Interessante.
----------------------------------------------------------------
...se così non fosse, come dice Marco, ci deve essere una spiegazione valida di configurazione, altrimenti cambio hoster.

con il mio è così, ed è uno dei più comuni, peccano su altre cose, ma non ho mai dovuto trafficare coi permessi e mi lascia i miei originali se voglio.

M.

[santograz]

Fortunatamente, non sono l'unico fesso:

http://help.joomla.org/content/view/40/132/

http://www.netadmintools.com/art560.html

[ritz2]

Mi sa che devo mettere in remoto il sito già bello e che fatto.
L'Host è gratuito e probabilmente è settato per non far scrivere niente.
Devo rivolgermi ad uno a pagamento, volevo solo fare delle prove prima di fare figuracce 
Ho settato tutte le cartelle a 777, nell'info sistema le cartelle sono tutte scrivibili, ma non riesco ad installare nulla.
Sono andato nella cartella TEMP ed ho notato che la cartella install_ecc. viene creata di default a 755 e quindi non permette la scrittura.

Ps: posso usare il configuration.php già creato in remoto con il sito già pronto che ho in locale?

[santograz]

Se non riesci ad installare neanche con le cartelle a 777 allora il problema è nel percorso della temp, nel configuration.php

Il test che trovi in info->permessi cartelle dà tutto verde?

[mmleoni]

ciao santograz,
 la cosa sta andando OT, quindi ti risponderò  solo per questa volta.

Vuoi dire che lavori su di un server non locale con i permessi della temp e della cache a 644 o anche a 755?

e questo da dove lo hai dedotto? ho detto che con tutti gli hosting con cui ho lavorato non ho mai dovuto cambiare niente niente per far funzionare il sito, semmai sono intervenuto per restringere i permessi MAI per ampliarli. comunque parlare di permessi in maniera disgiunta dalla ownership non ha senso...

... dicono che alcune cartelle devono essere scrivibili e perdono addirittura il tempo di inserire un test nel CMS, penso dobbiamo rispettare il loro lavoro.

certo che debbono essere scrivibili, ma che c'entra in questo contesto? stiamo dicendo che se non cambi esplicitamente i permessi sono scrivibili.

Avere le proprie idee è un diritto, divulgarle come legge è una cosa de fare con responsabilità.

è esattamente ciò che penso.


ciao,
marco

[mmleoni]

L'Host è gratuito e probabilmente è settato per non far scrivere niente.

ciao ritz2,
non avrebbe molto senso dare un servizio che non funziona, anche se gratuito. verifica la documentazione del provider, può darsi che ti stia sfuggendo qualcosa.
 
il fatto che i permessi siano a 755 non implica niente: visto che mi ci tirate vi dico che misterX imposta i propri server in questo modo e tutto funziona...
 
il configuration.php varia da macchina a macchina, quindi tipicamente è necessario modificare almeno qualche valore.

ciao,
marco

[ritz2]

Il test che trovi in info->permessi cartelle dà tutto verde?

E' tutto verde, era perché ho rinunciato ed ho messo il sito già pronto.
http://bertoniforgraf.xoom.it/
L'unico problema è che non posso entrare come admin, se metto una psw errata me lo segnala, se metto la giusta fa come per entrare poi torna al login, probabilmente è una questione di link o qualcosa da settare al configuration.php.

[ritz2]

L'unico problema è che non posso entrare come admin,

Anzi secondo me sto dentro, per esempio se sulla barra una volta fatto il login scrivo: miosito/administrator/index.php?option=com_messages, (o altro indirizzo administrator) si sposta di pagina senza dare l'errore di pagina non trovata, ma vedo sempre la pagina di login, che stranezza 
Anche perché vorrei sistemare dei componenti che non funzionano e prendere pratica prima di spostarmi su un host/professional.

[ritz2]

Risolto, il problema risiede nel configuration.php, ho trovato in rete un conf.php standard ho messo i miei dati, chiuso con un editor di testo più tecnico et voilà ha iniziato a funzionare.

[frascan]

Comunque, senza permessi di scrittura, non riesci neanche ad aggiungere un articolo a joomla

credo di capire lo spirito di questa tua affermazione che è un'iperbole stilisticamente parlando, però ti inviterei a tenere presente che in rete, ed il forum di joomla.it non fa eccezione, non si è tutti allo stesso livello di competenze e conoscenze quindi è meglio evitare affermazioni che possano generare confusione nelle persone meno esperte.

come certamente sai gli articoli di joomla vengono salvati nel database mysql su cui si appoggia e non c'entrano i permessi su files e cartelle in questo caso specifico.

giusto per dovere di chiarezza e per evitare confusione.

[santograz]

Una piccola (ed ultima) precisazione:

Quando, nel corso di questa discussione, ho parlato di "cambiare i permessi alle cartelle", mi riferivo esclusivamente a quelle cartelle indicate dal manuale d'installazione di Joomla ed evidenziate dal test in info->permessi cartelle.

[frascan]

Quando, nel corso di questa discussione, ho parlato di "cambiare i permessi alle cartelle", mi riferivo esclusivamente a quelle cartelle indicate dal manuale d'installazione di Joomla ed evidenziate dal test in info->permessi cartelle.

e questo è verissimo infatti e nessuno dice il contrario
la divergenza di opinioni è sul chmod da dare a files e cartelle 775 piuttosto che 777.
ma questo non per polemica o altro ma per il fatto che tu sai come muoverti e sai cosa implica dare un chmod 777 ma persone meno esperte possono fare grossi danni modificando a casaccio i permessi su files e cartelle; soprattutto in ambienti di hosting condiviso.
ci si preoccupa tanto di risolvere possibili bug di sicurezza negli scripts per poi mettere a repentaglio il tutto con un chmod troppo permissivo. questa la mia preoccupazione e questa è la motivazione che mi ha spinto a fare le mie precisazione.
e poi il confronto di idee è il sale della vita e non può che farci crescere ed imparare tutti insieme.
un saluto

[santograz]

Questo post diventerà un best seller!

Io non so "per dove" sei passato tu
Personalmente (ed in questo momento sto lavorando con almeno 6 provider, anche grossi, oltre che con 2 server dedicati) non ho veramente mai trovato un provider che faccia girare apache (e quindi gli script PHP) sotto lo stesso gruppo di tutti gli user. Di conseguenza, ormai, sono rassegnato a quel 777 che, per la mia esperienza, è diventato inevitabile.

Quanto al caso (755) in cui tutti gli user e lo stesso apache si chiamano "pippo", mi sembra fantascientifico, se non in locale. Questo non mi è piaciuto dell'articolo citato che tratta la configurazione user/apache sotto lo stesso UID come "Una configurazione tipica".

[mmleoni]

visto che sono continuamente tirato in ballo:

http://httpd.apache.org/docs/2.0/suexec.html

configurazione tipica negli hosting condivisi. oltre a suexec, che è universalmente conosciuto tra i sistemisti, esistono altre alternative per fare ciò che scrivevo, del resto su linux un processo può essere fatto girare con qualsiasi uid:gid. ma l'articolo non poteva essere una guida alla configurazione di un server.

chi si rivolge a questo forum in cerca di aiuto non è certo un sistemista e bisogna stare sempre attenti a dare consigli, soprattutto se non si è proprio ferratissimi.

io non ho dovuto mai modificare i permessi, se non per restringerli con nessuno dei provider con cui lavoro, forse sono fortunato, forse so come funziona una macchina.

e speriamo che l'argomento sia chiuso.
marco

[monica3]

Eh eh,
succede anche a me: il dito (sulla tastiera) è più veloce del cervello

lo hai detto proprio tu e ultimamente mi sembra si verifichi sempre più spesso.

monica

[mmleoni]

speravo lasciaste cadere la vicenda nel dimenticatoio, ma vedo che così non è.

http://help.joomla.org/content/view/40/132/
questa è una guida all'installazione di joomla 1.0 ed illustra l'istallazione base di un sistema, con un solo sito ed un solo utente, il cui ultimo aggiornamento risale a marzo 2007... chissà di quando è la prima stesura; configurare un server attuale con una guida di anni fa è un po' come voler attraversare roma con lo stradario di giulio cesare.

comunque vorrei far notare che qui è stato consigliato proprio il metodo sconsigliato dall'articolo. la prima impostazione, ovvero quella consigliata, anche se al contrario, ovvero facendo girare php come fosse l'utente, è quella adottata dalla pressoché totalità dei providers italiani e della vecchia europa.

comunque questo articolo dice di cambiare i permessi a 707, ovvero azzerare i permessi del gruppo.

http://www.netadmintools.com/art560.html
questo dice di cambiare il gruppo cui appartengono i files e di impostarlo a quello cui appartiene apache, dopo di che di dare i permessi di scrittura al gruppo.
esattamente il contrario di ciò che dice il precedente.

in ambo i casi vi è da chiedersi chi è l'utente alle prime armi che fa un ssh sul server.

ciò che va tenuto presente è che entrambi i testi sono corretti perché presuppongono la conoscenza di utente e gruppo: in difetto di tale informazione parlare di permessi non ha senso, ma serve solo a rendere insicuro il server.

in joomla 1.5 infatti la gestione dei permessi è stata eliminata dall'amministrazione e sostituita dal layer ftp in quanto:
Using the FTP Layer eliminates the need to make directories and files writable and thus improves overall security of the installation and server.


e speriamo di non doverci tornare, basta PM per cortesia.
marco