On Mar 13, Dmitry V. Levin wrote:
> On Thu, Mar 13, 2003 at 05:40:11PM +0100, Sergei Golubchik wrote:
> > > > Anyway, even though the current patch indeed allows one to change the
> > > > permissions between time of check and time of use, it's a
> > > > issue. Only the file owner can change the permissions! A malicious
> > > > would need to be the owner of that file, before he could do that.
> > >
> > > Btw, check for file ownership is also missing.
> > > I've added
> > > if (!getuid() && stat_info.st_uid) /* for root, ignore files owned
> by non-root */
> > > return 0;
> > It was intentional.
> > Unfortunately, there're too many setup where everything in datadir/
> > is owned by mysql user. Yes, it's bad, but we cannot introduce changes
> > in 3.23 that will break many existing installations.
> That is, the scenario described in Bugtraq will work in such setups. :(
No it will not.
Because SELECT ... OUTFILE always creates world-writeable files.
So this file will not be read my mysqld.
> > > > So I am not sure, if we would gain anything here by using fstat()
> > >
> > > You'll get a bit more secure code. :)
> > I cannot see how fstat() can make the code even slightly secure.
> > What is the scenario where changing stat() to fstat() can help ?
> It's quite common case:
> When you call stat before open, there is a race; attacker with rights of
> mysql user may subvert the file right after the check, and make root to
> follow his evil instructions.
Nope - it's just general words, they do not apply to this case.
It attacker has rights of mysql nothing prevents him from altering file
content and setting proper permissions before any check.
Why on the world he would like to make the file world-writeable between
stat() and open(). What will he gain ?
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany