On Thu, Mar 13, 2003 at 08:34:37PM +0100, Sergei Golubchik wrote:
> This particular race condition allows only one thing.
And it doesn't prevent another possible mysql->root attacks using
> > Using fstat together with st_uid check closes these issues, too.
> As I said, we cannot add st_uid check in 3.23 or 4.0.
At least, you could print a warning, that config file has insecure
ownership and/or permissions, so it's not portable (may be explicitly
disabled by vendor), deprecated and should be avoided.
Once more: without st_uid and S_IWGRP checks you cannot prevent another
possible mysql->root attacks.
> > After all, let's try to avoid potentially raceable constructions.
> This particular construction is not exploitable.
It is not exploitable using SELECT INTO OUTFILE method,
but it won't help from attacker with mysql rights.
In ALT GNU/*/Linux, we package MySQL chrooted to /var/lib/mysql by default,
with /var/lib/mysql owned by root, sticky bit set, etc.
All these efforts are void if mysql user is allowed to tamper with config
> Let's try to apply rules wherever they matter, and not where
> pattern-matching tool identifies a "potential vulnerability".
I'm sure that open/fstat check is not overkill in this particular case.
It adds no complexity as compared with stat/open check, and easier to
support: some day one will have to deal with that piece of code again...