RE: Tools und/oder Hilfen/Infos zu grants tables_priv und columns_priv

["Rico Koerner" <koerner_(at)_dd.heico.de>]

Schön, und was macht man ohne Zugriff auf die User-DB?

Z.B. bei Strato gibts eine zentrales MySQL-RDBMS,
der User erhält nur einen Account auf seine DB. :-((

Da muß man sich wohl selbst 'ne User-Tabelle anlegen und die
Zugriffe anderweitig kontrollieren.
(Oder einen anderen Provider suchen.)

Zurück zum Problem: Es macht in einigen Fällen auch Sinn, 
nicht nur Rechte auf ganze Datenbanken zu vergeben, 
sondern auch auf einzelne Tabellen oder Spalten.
Denk Dir mal eine Mitarbeiter-DB in der auch deine Lohndaten 
stehen. Darauf darf nur die Buchhaltung, nicht aber die Sekretärin
zugreifen die nur mal deine Adresse braucht.

Ciao, Rico.

> -----Original Message-----
> From: andreas kempf aka 'amalesh' [mailto:aka_(at)_bigfoot.de]
> Sent: Saturday, October 16, 1999 12:19 PM
> To: mysql-de_(at)_lists.4t2.com
> Subject: Re: Tools und/oder Hilfen/Infos zu grants tables_priv und
> columns_priv
> 
> 
> On Thu, 14 Oct 1999 22:14:03 +0200, Ralf Dieterle wrote:
> 
> >hat jemand Tools und/oder Hilfen/Infos zu
> >grants von tables_priv und columns_priv  ?
> 
> Ich erlaube mir, etwas von Martin Ramsch geschriebenes hier zu
> posten:
> 
> [...]
> Stattdessen erzeugt man gewöhnlich in MySQL einen Benutzer, indem
> man diesen Benutzer OHNE jegliche inhärente Rechte erzeugt:
> 
> INSERT INTO user (host, user, password)
>           VALUES ('fromhost', 'username', PASSWORD('gemein'));
> 
> Dieser User ist nun ein Nichts & Niemand. Er kann nix und darf auch
> nix. Ihm können jetzt für eine Datenbank einzelne, spezifische
> Rechte erteilt werden.
> In MySQL 3.22 sind dies die 6 Rechte select_priv, insert_priv,
> update_priv, delete_priv, create_priv, drop_priv, die die
> gleichnamigen SQL-Befehle freischalten.
> 
> Man macht also
> 
> INSERT INTO db ( host, db, user, 
>                  select_priv, 
>                  insert_priv, update_priv, delete_priv,
>                  create_priv, drop_priv)
>         VALUES ( '%', 'database', 'username', 
>                  'y',
>                  'y', 'y', 'y',
>                  'y', 'y');
> 
> Dabei sollte man folgende Dinge beachten: 
> 
> MySQL-Benutzer haben keinen Zusammenhang mit UNIX- oder
> NT-Benutzern, außer daß PHP sinnvolle Defaults dafür annimmt, wenn
> man beim Connect nix angibt (was man gewöhnlich aber tut).
> 
> MySQL-Benutzer haben immer die Form (username, fromhost), sodaß man 
> niemals einen Benutzer, sondern immer einen Benutzer von einem
> Rechner freischaltet. MySQL versteht hier SQL-Wildcards.
> 
> MySQL-Benutzer gibt es in 3 grundsätzlich sinnvollen
> Berechtigungsstufen:
> 
> - Rein lesender Zugriff -> Nur select_priv geben.
>   Dies ist sinnvoll bei rein lesenden Anwendungen, z.B. ein   
>   Spamgenerator, der sich die Adreßspalte einer Kundentabelle aus
>   der Datenbank liest.
> - Lesender und ändernder Zugriff -> select, insert, update, delete
>   geben.
>   Dies ist sinnvoll für alle normalen Webanwendungen, die auf eine
>   Datenbank editierend zugreifen (z.B. für das Admin-Interface zu
>   der o.a. Werbemüllschleuder)
> - Strukturverändernder Zugriff (die o.a. 4 Rechte + create + drop)
>   Dies ist oftmals nur zur Installation notwendig, damit die
>   benötigten Tables erzeugt und gelöscht werden können. Die meisten
>   Anwendungen brauchen diese Rechte nicht.
> 
> Damit MySQL die geänderten Zugriffsrechte zur Kenntnis nimmt, muß
> auf der  Kommandozeile "mysqladmin reload" gefahren werden.
> 
> hth
> 
> amalesh

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe