I was hoping that people who knew that they had fixed problems in 2.0.x
would you check that the 2.1.x tree is ok, like you did. "Distributed
checking". Often trying to forward-port fixes is hard simply because the
thing it fixes in 2.0.x may be done differently in 2.1.x.
However, this particular patch is an incomplete fix to the problem, even
on 2.0.x.
> + /* cevans - whoops another append-only file flaw */
> + if (IS_APPEND(file->f_dentry->d_inode) &&
> + (prot & PROT_WRITE))
> + return -EACCES;
The PROT_WRITE thing is ephemeral, and you can overcome this security fix
by just originally mapping it with PROT_NONE and then later doing a
"mprotect(PROT_WRITE)" on the area.
The proper (and now in my 2.1 tree) fix is to have
/* Make sure we don't allow writing to an append-only file.. */
if (IS_APPEND(file->f_dentry->d_inode) && (file->f_mode & 2))
return -EACCES;
which means that not only is it not a writable mapping now, it can never
become a writable mapping because the file descriptor was not writable.
Alternatively you could add another test to mprotect(), but I think it's
better to just completely disallow a shared mapping of a append-only file
descriptor that was opened with write mode. Anybody trying to do that
looks suspicious anyway.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html