> Having random scripts die with EOVERFLOW is IMHO a "blow up mysteriously"
> to the average user.
The average user has no files >=2GB. Everybody who deals with such
files in the moment knows the problems. And when s/he get told there
is an escape by using the 64 bit ops s/he'll probably walk this way.
> Oh look NFSv3 hasnt got such a bit, Oh look SMBfs hasn't got such a bit etc
I don't understand enough of all this VFS stuff to argue. But me
thinks that even for opaque file handles like the one for NFS there
must be a way to extract the position in the file etc. So one can add
this information locally !?
> Furthermore the denial of service and setuid application attacks possible
> on this are astronomical in scale if you can use setuid apps to "taint"
> 32bit files.
If someone can use setuid to enlarge a file beyond the "GB barier s/he
probably also can truncate it to zero and destroy all data. I don't
see how this is somethin different to normal security problems.
> Yes. Like an lseek on a 64bit file, or an mmap() that would go over
> 2^32 bytes. O_APPEND on a file over 2^32 bytes is an interesting one,
> perhaps that should fail in case the app then uses lseek.
Seems plausible.
> To be able to use normal unix file redirection my shell has to be one
> of them however.
Yes, and? We have the sources, the changes are trivial.
> Thats why its important that the applications continue
> to do the right thing, or as close as possible. "cat" for example works
> fine given a 64bit file and doing 32bit operations. Stuff like tail
> that does lseek won't. Thats why we want to stop the minimum number
> of operations.
Sorry, I don't understand the last sentence. If tail is still a 32
bit app which is used on a 2GB file it simply fails. I find this ok
since as soon as the first LFS application is installed on your system
all shell tools etc should also be replaced. Again, we have the
sources and the changes are trivial (and probably already in the
development code of the maintainer of these packages). Sun did it
like this: they ship 2.6 with the new interface and all system tools
rewritten to use the LFS interface.
I think we need not see the interface/libc change and the tools
separately: both upgrades will have to happen at the same time and
doing this is easy.
-- Uli
---------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------