Michael Tokarev wrote:
Bill Davidsen wrote:
If I got it right (and please someone tell me if I *really* got it right!),
the problem is elsewhere.
Suppose you have a filesystem, not at all related to databases and stuff.
Your usual root filesystem, with your /etc/ /var and so on directories.
Some time ago you edited /etc/shadow, updating it by writing new file and
renaming it to proper place. So you have that old content of your shadow
file (now deleted) somewhere on the disk, but not accessible from the
filesystem.
Now, a bad guy deliberately tries to open some file on this filesystem, using
O_DIRECT flag, ftruncates() it to some huge size (or does seek+write), and
at the same time tries to use O_DIRECT read of the data.
Which should be identified and zeros returned. Consider: I open a file
for database use, and legitimately seek to a location out at, say,
250MB, and then write at the location my hash says I should. That's all
legitimate. Now when some backup program accesses the file sequentially,
it gets a boatload of zeros, because Linux "knows" that is sparse data.
Yes, the backup program should detect this as well, so what?
My point is, that there is code to handle sparse data now, without
O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
with the idea of O_DIRECT, the kernel has a security problem.
Due to all the races etc, it is possible for him to read that old content of
/etc/shadow file you've deleted before.
I do have one thought, WRT reading uninitialized disk data. I would hope
that sparse files are handled right, and that when doing a write with
O_DIRECT the metadata is not updated until the write is done.
"hope that sparse files are handled right" is a high hope. Exactly because
this very place IS racy.
Other than assuring that a program can't read where no program has
written, I don't see a problem. Anyone accessing the same file with
multiple processes had better be doing user space coordination, and gets
no sympathy from me if they don't. In this case, "works right" does not
mean "works as expected," because the program has no right to assume the
kernel will sort out poor implementations.
Without O_DIRECT the problem of doing ordered i/o in user space becomes
very difficult, if not impossible, so "get rid of O_DIRECT" is the wrong
direction. When the program can be sure the i/o is done, then cleverness
in user space can see that it's done RIGHT.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
