Michael Widenius wrote:
> >>>>> "Thimble" == Thimble Smith <tim@stripped> writes:
> Thimble> At 18:27, 19990820, Christian Mack wrote:
> >> What I think of is something like that:
> >> SET OPTION PASSWORD=... [NO_LOG] [NO_UPDATE_LOG]
> >> With that enhanced syntax, you could leave both "SET OPTION SQL_LOG..."
> commands untouched (= restricted to user with PROCESS priviledge).
> Thimble> I like it. But I would also like the admin to be able to tell who
> Thimble> changed a password when from what IP. Could the log file still record
> Thimble> the command, but XXXXXX the password string or something?
> Thimble> [ Note: I don't need this feature. If others don't think that this ]
> Thimble> [ is important, then I don't either. ]
> The major problem with not updating the UPDATE LOG is that in this
> case we will get problems in the upcoming replication handling (this
> will be done with the MyODBC update log).
But how do you handle then the case of an priviledged user which updates her password
while logging is turned off?
This wouldn't show up in replication either.
Perhaps you should make two different streams.
The first one for replicating to other mysqls and the second one for logging?
Then the first one could contain all changes whether logging is on or off.
But then you have to prevent saving of the replication stream.
Perhaps you could send this stream direct via an builtin mysql client part over TCP/IP to
the remote mysqlsd's, which are given through a new priviledge table?
To prevent looping replications you could create an special mysql user.
This one only sends her changes to the log, but not to the replication stream.
What do you think Monty?