Privilegi da dare all'utente per mysql in produzione

Non è solo la SQL-Injection il pericolo.
Proprio non vorrei dare tanto potere all'utente web, se chi gestirà il sito si fa scappare (o sceglie male) le pwd come la mettiamo?

Bah, non me l'aspettavo proprio questa vulnerabilità :-(

I permessi di mysql si dividono in 3 categorie: dati, struttura ed amministrazione. Il permesso di DELETE ovviamente è tra quelli di dati e non vedo perchè all'utente dovrebbe esser bloccata la possibilità di cancellare un record della PROPRIA tabella nel PROPRIO database.
Ho sempre preferito non dare la possibilità di cancellare per due motivi:
1.- Non è possibile a qunto mi consta (correggimi se sbaglio, ma evitami il sarcasmo gratuito :-) ripristinare un record cancellato.
Personalmente non ho mai dato la possibilità di cancellare, ma di nascondere un contenuto, per poterlo sia recuperare che riciclare;

2.- Al di là di ogni possibile artificio che uno puo' mettere in campo, tengo sempre a mente che "nulla puo' la Forza contro la stupidaggine degli utonti".
E visto che ci sono infinite possibilità perché una pwd diventi di pubblico dominio (sotto la tastiera, la data di nascita, il nome del figlio, i post-it sul monitor [ho visto anche questo in aziende], cracking di server etc.), se il lamer di turno riesce a sostituirsi ad un admin, meglio che possa solo "nascondere" piuttosto che cancellare.

Sul LOCK ho detto chiaramente "no problem", quindi evitami please "la sparata" :-)
Il "System Requirements", l'ho letto prima di decidere per Drupal, ed ho visto che si parla solo di lock tables, non di DELETE né di DROP.
Piuttosto faresti bene a rileggerti il file "install.txt", che dalla riga 78 alla 98 recita testualmente:

Again, you will be asked for the 'dba_user' database password.
At the MySQL prompt, enter following command:

GRANT ALL PRIVILEGES ON drupal.*
TO nobody@localhost IDENTIFIED BY 'password';

where

'drupal' is the name of your database
'nobody@localhost' is the username of your webserver MySQL account
'password' is the password required to log in as the MySQL user

If successful, MySQL will reply with:

Query OK, 0 rows affected

To activate the new permissions you must enter the command:

flush privileges;

and then enter '\q' to exit MySQL.

Spero che tu non abbia seguito alla lettera queste istruzioni per il tuo sito! :-D
Perché se, come spero, tu hai ignorato questa raccomandazione, lo stesso non credo proprio che si possa dire del 90% di chi usa un CMS open-source, che proprio non so fino a che punto si rende conto di che vuol dire GRANT ALL ... TO nobody@localhost o comunque di sicurezza (almeno) di base!

Ora somma il "System requirements" che mi segnali tu e l'"install.txt": ti sembra ancora così assurdo che io mi chieda se prima o poi dovrò concedere il DROP???

Mi rendo conto che non mi conosci (come io non conosco te), ma sappi che da qualche anno faccio questo lavoro e porto a casa il companatico per la famiglia, non sono l'ultimo arrivato, ed avrei sinceramente preferito una risposta costruttiva piuttosto che il sarcasmo.

E per finire:
Per quanto riguarda le password, spero che tu stia scherzando perchè questo non è affato un bug o una vulnerabilità. Rispondi a questa domanda: che succede se perdi il bancomat e il codice segreto? che succede se perdi il nome utente e la password di bancoposta? che succede se perdi la password dell'utente root o dell'amministratore di windows?

1.- Tanto per cominciare ricorda (o sappi) che la stessa presenza di una pwd o cmq di una restrizione comporta una vulnerabilità intrinseca: la curiosità umana (e non sto scherzando né facendo sarcasmo!).

2.- [bancomat] Chiamo la banca e/o la posta e faccio bloccare la carta, ho i numeri sulla rubrica del telefonino... tu ci hai pensato?

3.- [bancoposta] Come 2. con l'aggiunta che la "cassetta e-mail" di bancoposta non la uso in rete, ma solo per ricevere le e-mail del "sistema" (e taccio... ne avrei di cose da raccontare!!!!)

4.- [pwd root] Sia che si tratti di Windows che di Linux (e se tanto mi da' tanto anche mac etc) prendo il mio disco "inaccessibile", lo monto come slave su un altro pc, e recupero TUTTO MA PROPRIO TUTTO ciò che mi serve.
Altrimenti per linux (mi dicono, non ho ancora avuto il piacere) basta un cd d'installazione, così come per Windows.
4.a- Certo sempre che il disco non sia cifrato/criptato... ma uno dovrebbe essere pazzo a cifrare/criptare perché la rottura meccanica è sempre dietro l'angolo.

Infine (e termino davvero) ti invito a leggere:
http://drupal.org/node/39175
e
http://drupal.org/search/node/database+privileges

Sembra che per fortuna io non sia il solo ad tenere i neuroni sempre in moto :-)

-----------------------------------------------------------------
Detto questo, e mi scuro per la prolissità... ma se mi provocate... qualcuno è in grado di confermarmi che: SELECT UPDATE INSERT LOCK DELETE sono i soli ed unici privilegi che devo concedere all'utente localhost?

Le notizie le puoi mettere nella coda di moderazione se non vuoi renderle visibili e le recuperi dal menu contenuti.
E chi ha parlato di "notizie"?
Io sto parlando di record dal database... è un pelino diversa la cosa!

La parola "sparata" era riservata al drop perchè in quel caso l'avevi sparata inteso come scrivere un qualcosa solo per parlare.
Quando parlo di lavoro e sicurezza non parlo mai per parlare.
Ne va dimezzo l'immagine (ed il portafogli).
Se da nessuna parte trovo scritto "non è necessario il drop" mi sembra lecito chiedermi "non è che in qualche situazione assurda dovrò dare il drop?"

Per installarlo serve la possibilità di poter gestire il database in tutti i suoi aspetti
E non manca nulla in quel readme o nei requirements secondo te?
Dove sta scritto "ATTENTO DEVI USARE ALL SOLO QUANDO INSTALLI POI TOGLI ALL ED USA SOLO SELECT... etc" ???
Leggi requirements e readme da un punto di vista dell'utente inesperto o cmq non skillato come siamo noi che cosa pensi che farà?
Non sono mai partito in quarta quando lavoro, e non sto deducendo cose sbagliate.
Ancora non ho trovato scritto da nessuna parte (precisazione) "quali privilegi servono a drupal durante il funzionamento"?

" 2.- [bancomat] ...
In Drupal fai la stessa cosa.... ci hai pensato?
E' questo il punto: il bancomat può cadere insieme al portafoglio se ho la tasca un po' scucita.
Consentire il DELETE significa usare un filo di seta per tenere a posto il portafoglio piuttosto che un bel cotone massiccio da jeans! :-)

****"http://drupal.org/node/39175"****
Questo sopra non c'entra nulla con i privilegi sul database
No, ma c'entra con la gestione degli utenti.
Io avrei sinceramente preferito non dare l'account di admin sul sito alla redazione (parlo di questo sito) e consentirgli tranquillamente di gestire in autonomia gli utenti che si registrano.
Non mi interessa minimamente tenere per me i privilegi (non l'ho mai fatto, ci pensa il contratto a tutelarmi) ma se per errore modificano l'utente root? O se inavvertitamente consentono i privilegi di modifica users ad un utente registrato?
E' come se un SUPERUSER potesse modificare l'account ADMIN, riesci a capire?
Non c'entra con la domanda principale, te lo concedo, ma sei d'accordo con me che è comunque una gravissima pecca specialmente se consideri che anche l'utente admin (di drupal) puo' essere cancellato grazie al privilegio DELETE sul db?

http://drupal.org/search/node/database+privileges
Non mi sembra venga aggiunto altro rispetto a ciò che ti è già stato detto.
Peccato che questa richiesta (la sesta dall'alto nel momento in cui scrivo) sia senza risposta da 6 mesi!

Ho la vaga impressione che ...
Io parlo e continuo a parlare di "privilegi dell'utente nobody@localhost rispetto al database".
Più chiaro di così riesco solo a disegnartelo :-)

Comunque mi sembra che non sai darmi una risposta alla mia precisa domanda, o sbaglio?

Vogliamo parlare di sicurezza?
Come mai in questo momento ci sono due persone (per un totale di 3 diversi browser su 2 diverse connessioni a internet) contemporaneamente loggate con il mio userid?
Io ho due browser (Mozilla e Firefox) contemporaneamente loggati, ed il mio sistemista è loggato anch'esso... CONTEMPORANEAMENTE!
In pratica è come se ci fossero dei cloni del mio bancomat!
Dimmi tu se anche questa non è una vulnerabilità.

---------------------------------
Per amor di precisione: non è mia intenzione denigrare Drupal, mi è piaciuto lavorarci (ne ho provati altri prima di optare per Drupal, fra cui xoops, mambo e non ricordo più quali) e lo riutilizzerò se ne avrò l'occasione, ti sto solo facendo notare che anche Drupal, come tutti i software, ha delle vulnerabilità.
E come tutti i software, anch'esso porge il fianco. E' questo che mi dispiace.

Con notizie ovviamente intendo nodo, ...
Tu forse, io fin dall'inizio ho sempre parlato (o sottinteso) di contenuti riferendomi al DB ed ai suoi pivilegi.

Tu confondi gli utenti con cui ti colleghi al database (e relativi permessi) con gli utenti drupal e relativi permessi.
Dimentichi che nulla puo' fare un utente drupal che non sia consentito anche all'utente nobody@localhost.
Se è possibile cancellare un record da una tabella, è possibile (virtualmente) cancellare da tutte.

Per il resto:

- Non ho mai parlato di query arbitrarie (posso solo fidarmi di drupal come di altri), ma solo del pericolo che qualcuno venuto in possesso di una pwd che non gli compete (non dico di admin, anche solo di redazione tanto per restare al mio caso specifico) potrebbe virtualmente cancellare tutti i record dal database o almeno i contenuti del sito (meglio così? :-), e ciò è male e da evitare.
E' vero che ci sono sempre i backup da restorare, ma fra riparare un danno e prevenirlo c'è una sottile differenza.

- riguardo agli utenti multipli, io la considero una vulnerabilità (opinione personale, lo ammetto) almeno nel caso di un sito quando c'è una macchina remota che dialoga con un'alta macchina remota(*), perché il sistema, per la sua integrità, dovrebbe "sapere" che in un istante puo' dialogare solo con un'istanza di admin (o cmq di utente) per volta.
(*) Ho volontariamente parlato di "macchine" e non di "macchina e utente", perché il server sa soltanto che c'è un browser, che gira su un pc, che si è autenticato. Chi effettivamente stia digitando sulla tastiera non lo sa né il server né tantomeno il client!
Questo è inevitabile, ma due o più browser autenticati contemporaneamente con la stessa credenziale, IMHO, sarebbe meglio evitarli.

- pwd di admin alla redazione: tralsciando che ovviamente il contratto con l'hoster è loro, ed hanno tutte le info di accesso al sito com'è giusto che sia, se il sistema (drupal) mi obbliga a consentire la modifica di qualsiasi utente anche ad un utente minore, tanto vale che gli do' direttamente la pwd di admin.
Chi gli vieta altrimenti a cambiarla da se e tagliarmi fuori?
In questo modo, almeno finché non saranno abbastanza skillati, si prenderanno la briga di avvisarmi quando cambiano la pwd di admin (per i più svariati motivi) visto che, al momento, sono l'unico che puo' configurargli il sito.
Quindi sta a loro gestire con oculatezza le pwd.

Sì, su questo hai ragione al 100%, ma se la tua domanda fosse stata precisa fin dall'inizio ...
Io fin dall'inizio ho parlato, e se vuoi puoi verificare, di privilegi rispetto al database.
Tutto il resto (utenti etc) è venuto fuori per la tua (consentimelo) saccenza, visto che alla fine riconosci che i privilegi che ho scoperto io sono gli unici necessari.

La tua conferma mi conforta visto che usi Drupal da almeno 9 mesi, spero davvero che siano tutti e soli.

Con questo chiudo per quel che mi riguarda.
Non amo ripetermi di persona, tanto meno impiegare del tempo a precisare e puntualizzare nei confronti di chi mi ascolta (o legge) superficialmente.

Senza rancore nè risentimento alcuno, solo un po' di delusione per una discussione che sarebbe potuta, e dovuta, essere più stimolante.

Buon weekend!

Ti ringrazio per questa patch, mi avrebbe richiesto molto tempo trovare il punto giusto visto che sto smanettando il drupo da meno di un mese.

Un problema in meno è già qualcosa :-)

Tnx again!
 
 
 
p.s. per drupalitalia.org
Perché non abilitare di default l'indentazione delle reply nel forum?
Questa possibilità è stata uno dei principali motivi che mi ha fatto scegliere Drupal rispetto ad altri.