Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22434 > unrolled thread

[OT] Utenti MySQL e permessi

Back to article view | Back to it.comp.www.php

Contents

  [OT] Utenti MySQL e permessi ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-18 15:15 +0100
    Re: [OT] Utenti MySQL e permessi bramante <bramante@yopmail.com> - 2018-12-18 20:44 +0100
      Re: [OT] Utenti MySQL e permessi ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-18 21:18 +0100
        Re: [OT] Utenti MySQL e permessi bramante <bramante@yopmail.com> - 2018-12-18 22:27 +0100
          Re: [OT] Utenti MySQL e permessi ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-18 22:45 +0100
            Re: [OT] Utenti MySQL e permessi bramante <bramante@yopmail.com> - 2018-12-18 23:30 +0100
              Re: [OT] Utenti MySQL e permessi ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-19 19:31 +0100
                Re: [OT] Utenti MySQL e permessi bramante <bramante@yopmail.com> - 2018-12-20 21:32 +0100
                  Re: [OT] Utenti MySQL e permessi ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-22 10:27 +0100

#22434 — [OT] Utenti MySQL e permessi

Salve,

ringrazio prima di tutto quelli che hanno risposto al mio precedente 
post sulla doppia chiave, il discorso si è poi allargato ed ho lasciato 
correre!

Sto studiando appunto come lavora MySQL e MariaDB, volevo un chiarimento 
sul discorso della creazione degli utenti:

root@host# mysql -u root -p
Enter password:*******
mysql> use mysql;
Database changed

mysql> INSERT INTO user
    (host, user, password,
    select_priv, insert_priv, update_priv)
    VALUES ('localhost', 'guest',
    PASSWORD('guest123'), 'Y', 'Y', 'Y');
Query OK, 1 row affected (0.20 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 1 row affected (0.01 sec)

Nello specifico con questo comando creo semplicemente un utente 
nell'archivio che di default non avrà accesso ad alcun database giusto?

Nel seguente modo andrò poi a dire che quell'utente avrà accesso ad un 
determinato database?

root@host# mysql -u root -p password;
Enter password:*******
mysql> use mysql;
Database changed

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    -> ON TUTORIALS.*
    -> TO 'guest'@'localhost'
    -> IDENTIFIED BY 'guest123';

Il discorso permessi degli utenti è fondamentale e non vorrei sbagliare 
l'abc!

Saluti.
^Bart

[toc] | [next] | [standalone]

#22435

Il 18/12/18 15:15, ^Bart ha scritto:
> Salve,
> 
> ringrazio prima di tutto quelli che hanno risposto al mio precedente 
> post sulla doppia chiave, il discorso si è poi allargato ed ho lasciato 
> correre!
> 
> Sto studiando appunto come lavora MySQL e MariaDB, volevo un chiarimento 
> sul discorso della creazione degli utenti:
> 
> root@host# mysql -u root -p
> Enter password:*******
> mysql> use mysql;
> Database changed
> 
> mysql> INSERT INTO user
>     (host, user, password,
>     select_priv, insert_priv, update_priv)
>     VALUES ('localhost', 'guest',
>     PASSWORD('guest123'), 'Y', 'Y', 'Y');
> Query OK, 1 row affected (0.20 sec)
> 
> mysql> FLUSH PRIVILEGES;
> Query OK, 1 row affected (0.01 sec)
> 
> Nello specifico con questo comando creo semplicemente un utente 
> nell'archivio che di default non avrà accesso ad alcun database giusto?
> 
> Nel seguente modo andrò poi a dire che quell'utente avrà accesso ad un 
> determinato database?
> 
> root@host# mysql -u root -p password;
> Enter password:*******
> mysql> use mysql;
> Database changed
> 
> mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
>     -> ON TUTORIALS.*
>     -> TO 'guest'@'localhost'
>     -> IDENTIFIED BY 'guest123';
> 
> Il discorso permessi degli utenti è fondamentale e non vorrei sbagliare 
> l'abc!
> 
> Saluti.
> ^Bart


NON inserire lo user direttamente nella tabella ma utilizza i comandi 
che ti mette a disposizione mysql

- create user 'utente'@'host' IDENTIFIED BY 'password';

create user è il comando che dice a mysql di creare un utente
'utente'@'host' è il nome utente e da quale host ha accesso, in genere 
localhost o un indirizzo ip (o dns) specifico), eviterei il '%' che 
indica che ci si può connettere da qualsiasi ip (specialmente in produzione)
IDENTIFIED BY 'password' è la password che scegli.

GRANT SELECT, INSERT, UPDATE, DELETE ON DATABASE.TABELLE TO 'user'@'host';

evita di dare accesso DROP, CREATE o altro ad un utente se non 
strettamente necessario

poi crea un SOLO utente che verrà utilizzato dalla tua applicazione e da 
quale host si connette (in genere localhost se l'applicazione risiede 
nella stessa macchina di mysql)

Ciao

[toc] | [prev] | [next] | [standalone]

#22436

Ti ringrazio per iniziare per la risposta! :)

> NON inserire lo user direttamente nella tabella ma utilizza i comandi 
> che ti mette a disposizione mysql

Giusto per sapere, inserendo un utente nella tabella mysql posso creare 
altri utenti di "controllo" su tutti i database o su alcuni giusto per 
non dare l'utenza root a tutti?

> - create user 'utente'@'host' IDENTIFIED BY 'password';

Ok.

> create user è il comando che dice a mysql di creare un utente
> 'utente'@'host' è il nome utente e da quale host ha accesso, in genere 
> localhost o un indirizzo ip (o dns) specifico), eviterei il '%' che 
> indica che ci si può connettere da qualsiasi ip (specialmente in 
> produzione)

Quindi 'pippo'@'192.168.1.x' oppure 'pippo'@'localhost', per dns 
specifico cosa intendi? Tipo se avessi un server dns locale tutti quelli 
che girano in quel dns potrebbero collegarsi direttamente come client al 
database presente su server eseguendo dal client gli script?

Il % sarebbe da sostituire a @ per avere quello che dici? Giusto per 
sapere ho capito la pericolosità del tutto! :)

> IDENTIFIED BY 'password' è la password che scegli.

Ok, in questo caso viene archiviata crittografata o in chiaro?

> GRANT SELECT, INSERT, UPDATE, DELETE ON DATABASE.TABELLE TO 'user'@'host';
> 
> evita di dare accesso DROP, CREATE o altro ad un utente se non 
> strettamente necessario

Capito.

> poi crea un SOLO utente che verrà utilizzato dalla tua applicazione e da 
> quale host si connette (in genere localhost se l'applicazione risiede 
> nella stessa macchina di mysql)

Perfetto, capito anche questo, grazie ancora! :)

> Ciao

Saluti!
^Bart

[toc] | [prev] | [next] | [standalone]

#22437

Il 18/12/18 21:18, ^Bart ha scritto:
> Ti ringrazio per iniziare per la risposta! :)
> 
>> NON inserire lo user direttamente nella tabella ma utilizza i comandi 
>> che ti mette a disposizione mysql
> 
> Giusto per sapere, inserendo un utente nella tabella mysql posso creare 
> altri utenti di "controllo" su tutti i database o su alcuni giusto per 
> non dare l'utenza root a tutti?

in genere è il DBA che crea gli utenti e lo schema del DB con le 
relative tabelle, indici, trigger, partizioni e tutti gli oggetti necessari.
comunque puoi creare un utente "superuser" che ha funzioni particolari, 
come creare schema (i db in mysql), altri utenti e assegnare grant ecc.

come fa ad esempio aruba o altri che danno un instanza mysql nei loro 
piani hosting.
ti offrono un utente superuser ma non root, infatti non puoi effettuare 
le tipiche operazioni da DBA (come il start/stop del DBMS, 
partizionamento, quota, performance di processo, backup/restore ecc)


> 
>> - create user 'utente'@'host' IDENTIFIED BY 'password';
> 

> Quindi 'pippo'@'192.168.1.x' oppure 'pippo'@'localhost', per dns 
> specifico cosa intendi? Tipo se avessi un server dns locale tutti quelli 
> che girano in quel dns potrebbero collegarsi direttamente come client al 
> database presente su server eseguendo dal client gli script?
> 

per dns intendo un nome di dominio come miodominio.it o un terzo livello 
come app.miodominio.it, www.miodomino.it ecc



> Il % sarebbe da sostituire a @ per avere quello che dici? Giusto per 
> sapere ho capito la pericolosità del tutto! :)
> 

'%' al posto di 'localhost' o 'indirizzo_ip' o 'miodominio'

'user'@'%' (fortemente sconsigliato)


>> IDENTIFIED BY 'password' è la password che scegli.
> 
> Ok, in questo caso viene archiviata crittografata o in chiaro?

la password inserita viene crittografata

Ciao

[toc] | [prev] | [next] | [standalone]

#22438

> in genere è il DBA che crea gli utenti e lo schema del DB con le 
> relative tabelle, indici, trigger, partizioni e tutti gli oggetti 
> necessari.
> comunque puoi creare un utente "superuser" che ha funzioni particolari, 
> come creare schema (i db in mysql), altri utenti e assegnare grant ecc.

Chiarissimo, il discorso superuser citando per così dire terminologie 
del mondo Linux! :D

> come fa ad esempio aruba o altri che danno un instanza mysql nei loro 
> piani hosting.
> ti offrono un utente superuser ma non root, infatti non puoi effettuare 
> le tipiche operazioni da DBA (come il start/stop del DBMS, 
> partizionamento, quota, performance di processo, backup/restore ecc)

Bene, ho capito, non ero mai andato così addentro alla situazione di 
Aruba pur avendo avuto in passato dei piani hosting certo che il 
discorso backup restore sarebbe stato comodo, curiosità come si potrebbe 
agire in tal senso non potendolo fare a livello "base"?

> per dns intendo un nome di dominio come miodominio.it o un terzo livello 
> come app.miodominio.it, www.miodomino.it ecc

Il discorso degli indirizzi ip lo conosco ma non capisco creando un 
utente 'pippo'@'www.miodominio.it' chi potrebbe accedere o meglio forse 
ho capito, tutte le richieste che partono dal sito www.miodominio.it 
verso il server remoto che ospita il database ma in questo caso perchè 
si agirebbe in questo modo? Non è rischioso far partire un tale permesso 
da remoto? Ci sono attacchi dns ad esempio che sarebbero un bel problema...

Forse a livello enterprise giustamente si dividono i server e quindi da 
una parte gira apache e dall'altra mysql/mariadb?

> '%' al posto di 'localhost' o 'indirizzo_ip' o 'miodominio'
> 
> 'user'@'%' (fortemente sconsigliato)

Ok, si lo sconsiglio l'avevo capito quello che mi sfuggiva era il 
posizionamento del carattere, potrebbe capitare di doverlo controllare 
anche perchè compiuto da terzi per questo ho chiesto delucidazioni!

> la password inserita viene crittografata

Mentre quando inserisci un utente dentro al db mysql devi scrivere 
PASSWORD altrimenti rimane in chiaro giusto?

> Ciao

Saluti e grazie ancora! :)
^Bart

[toc] | [prev] | [next] | [standalone]

#22439

Il 18/12/18 22:45, ^Bart ha scritto:
>> in genere è il DBA che crea gli utenti e lo schema del DB con le 
>> relative tabelle, indici, trigger, partizioni e tutti gli oggetti 
>> necessari.
>> comunque puoi creare un utente "superuser" che ha funzioni 
>> particolari, come creare schema (i db in mysql), altri utenti e 
>> assegnare grant ecc.
> 
> Chiarissimo, il discorso superuser citando per così dire terminologie 
> del mondo Linux! :D
> 
>> come fa ad esempio aruba o altri che danno un instanza mysql nei loro 
>> piani hosting.
>> ti offrono un utente superuser ma non root, infatti non puoi 
>> effettuare le tipiche operazioni da DBA (come il start/stop del DBMS, 
>> partizionamento, quota, performance di processo, backup/restore ecc)
> 
> Bene, ho capito, non ero mai andato così addentro alla situazione di 
> Aruba pur avendo avuto in passato dei piani hosting certo che il 
> discorso backup restore sarebbe stato comodo, curiosità come si potrebbe 
> agire in tal senso non potendolo fare a livello "base"?

puoi fare un logical backup (con mysqldump) dump/load del db, che è cosa 
ben diversa di fare un backup. il comando mysqldump non fa altro che 
ricreare in un file di testo (.sql) tutte le DDL e SQL necessarie per 
ricreare lo schema e i dati.
questo comporta la perdita di una miriade di informazioni, come il 
logical volume, struttura e file del db, le informazioni delle 
transazioni, i log ecc..

> 
>> per dns intendo un nome di dominio come miodominio.it o un terzo 
>> livello come app.miodominio.it, www.miodomino.it ecc
> 
> Il discorso degli indirizzi ip lo conosco ma non capisco creando un 
> utente 'pippo'@'www.miodominio.it' chi potrebbe accedere o meglio forse 
> ho capito, tutte le richieste che partono dal sito www.miodominio.it 
> verso il server remoto che ospita il database ma in questo caso perchè 
> si agirebbe in questo modo? Non è rischioso far partire un tale permesso 
> da remoto? Ci sono attacchi dns ad esempio che sarebbero un bel problema...

pensa a un applicazione dove ci sono più nodi in load balance, o su reti 
diverse, oppure applicazioni che devono scalare all'occorrenza dinamicamente

se fosse aperto a tutti '%' una possibile falla nella rete esporrebbe 
l'accesso al db da qualsiasi ip, gli attacchi dns, la maggior parte di 
tipo MIM  (men in the middle) per riuscire devono catturare il traffico 
tra il l'ip di dominio e il server mysql.

se fosse solo 'user'@'localhost' non hai possibilita di avere un 
applicazione scalabile o risiedere al di fuori della stessa macchina del db.

avere degli indirizzi ip fissi 'user'@'192.168.10.1' ti costringe a 
modificare la configurazione del db aggiungendo altri ip nel momento in 
cui scali o cambi ip (magari perchè campi fornitori di hosting o cambia 
la tipologia della rete)

> 
> Forse a livello enterprise giustamente si dividono i server e quindi da 
> una parte gira apache e dall'altra mysql/mariadb?

ma anche un cluster di DBMS o pensa ad una architettura a microservizi.

dove  l'applicazione e strutturata in modo che ogni piccola parte è un 
servizio a se stante che risiede su piu macchine.

faccio un esempio.

prendi un applicazione che faccia  prenotazione di qualsivoglia, magari 
la ricerca del ristorante/albergo/vattelapesca è demandata ad un 
servizio (microservices) con una sua logica applicativa disposta su 
diverse macchine sparse per il globo (una in irlanda,in USA, cina ecc) 
in load balance, mentre la parte della prenotazione avviene tramite 
altro servizio, anch'esso sparso e su macchine differenti, mentre magari 
il pagamento con Carta di credito è a sua volta l'ennesimo servizio 
ecc..ecc.. ecc..


> 
>> la password inserita viene crittografata
> 
> Mentre quando inserisci un utente dentro al db mysql devi scrivere 
> PASSWORD altrimenti rimane in chiaro giusto?

certo
> 
>> Ciao
> 
> Saluti e grazie ancora! :)
> ^Bart

[toc] | [prev] | [next] | [standalone]

#22440

> puoi fare un logical backup (con mysqldump) dump/load del db, che è cosa 
> ben diversa di fare un backup. il comando mysqldump non fa altro che 
> ricreare in un file di testo (.sql) tutte le DDL e SQL necessarie per 
> ricreare lo schema e i dati.
> questo comporta la perdita di una miriade di informazioni, come il 
> logical volume, struttura e file del db, le informazioni delle 
> transazioni, i log ecc..

Ok, tu ad un superuser che possa ad esempio eseguire un backup quali di 
questi parametri avresti dato:

     Select_priv
     Insert_priv
     Update_priv
     Delete_priv
     Create_priv
     Drop_priv
     Reload_priv
     Shutdown_priv
     Process_priv
     File_priv
     Grant_priv
     References_priv
     Index_priv
     Alter_priv

> pensa a un applicazione dove ci sono più nodi in load balance, o su reti 
> diverse, oppure applicazioni che devono scalare all'occorrenza 
> dinamicamente
> 
> se fosse aperto a tutti '%' una possibile falla nella rete esporrebbe 
> l'accesso al db da qualsiasi ip, gli attacchi dns, la maggior parte di 
> tipo MIM  (men in the middle) per riuscire devono catturare il traffico 
> tra il l'ip di dominio e il server mysql.

Tutto corretto se si pensa ad applicazioni di un certo livello o 
quantomeno in un ambito dove tu sei root di tutto, in uno sharing 
hosting sarebbe impensabile una cosa del genere! :)

> se fosse solo 'user'@'localhost' non hai possibilita di avere un 
> applicazione scalabile o risiedere al di fuori della stessa macchina del 
> db.

Ok però dovresti avere una gestione del dominio quindi un server dns, 
etc. etc. etc. come accennato sopra il tutto sarebbe riconducibile ad un 
discorso di alto livello, il singolo db, il singolo sito che muove poco 
traffico vivrebbe tranquillamente in localhost!

> avere degli indirizzi ip fissi 'user'@'192.168.10.1' ti costringe a 
> modificare la configurazione del db aggiungendo altri ip nel momento in 
> cui scali o cambi ip (magari perchè campi fornitori di hosting o cambia 
> la tipologia della rete)

Capito!

> ma anche un cluster di DBMS o pensa ad una architettura a microservizi.
> 
> dove  l'applicazione e strutturata in modo che ogni piccola parte è un 
> servizio a se stante che risiede su piu macchine.
> 
> faccio un esempio.
> 
> prendi un applicazione che faccia  prenotazione di qualsivoglia, magari 
> la ricerca del ristorante/albergo/vattelapesca è demandata ad un 
> servizio (microservices) con una sua logica applicativa disposta su 
> diverse macchine sparse per il globo (una in irlanda,in USA, cina ecc) 
> in load balance, mentre la parte della prenotazione avviene tramite 
> altro servizio, anch'esso sparso e su macchine differenti, mentre magari 
> il pagamento con Carta di credito è a sua volta l'ennesimo servizio 
> ecc..ecc.. ecc..

Chiaro.

Saluti!
^Bart

[toc] | [prev] | [next] | [standalone]

#22451

Il 19/12/18 19:31, ^Bart ha scritto:
>> puoi fare un logical backup (con mysqldump) dump/load del db, che è 
>> cosa ben diversa di fare un backup. il comando mysqldump non fa altro 
>> che ricreare in un file di testo (.sql) tutte le DDL e SQL necessarie 
>> per ricreare lo schema e i dati.
>> questo comporta la perdita di una miriade di informazioni, come il 
>> logical volume, struttura e file del db, le informazioni delle 
>> transazioni, i log ecc..
> 
> Ok, tu ad un superuser che possa ad esempio eseguire un backup quali di 
> questi parametri avresti dato:
> 
>      Select_priv
>      Insert_priv
>      Update_priv
>      Delete_priv
>      Create_priv
>      Drop_priv
>      Reload_priv
>      Shutdown_priv
>      Process_priv
>      File_priv
>      Grant_priv
>      References_priv
>      Index_priv
>      Alter_priv
> 

se devi simulare il comando mysqldum, che è quello che fa phpMyAdmin 
quando fai export

https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html

quelle che non sono server administrations



fai prima ad avere
https://github.com/ifsnop/mysqldump-php

[toc] | [prev] | [next] | [standalone]

#22459

> se devi simulare il comando mysqldum, che è quello che fa phpMyAdmin 
> quando fai export
> 
> https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html
> 
> quelle che non sono server administrations
> 
> 
> 
> fai prima ad avere
> https://github.com/ifsnop/mysqldump-php

Ti ringrazio per entrambi i link, ho capito anch'io che si fa prima a 
caricarsi myslqdump-php piuttosto che smattirsi con i permessi, a me 
interessava, come ti accennavo, avere un utente root e "x" utenti super 
user in grado di fare il backup, quando caricherò quel software dovrò 
capire se e come si possa fare quello che voglio!

Di sicuro poi se volessi avere "x" utenti in grado da soli di crearsi un 
loro database e di avere in questo "libero accesso" (quello che accade 
negli shared hosting) dovrei comunque studiarmi i permessi e dovrei 
comunque crearmi gli utenti dentro al db mysql...

Saluti.
^Bart

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web