lkml.org 
[lkml]   [1997]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: B*gg*r mallocs, mmap JOY!
Date
John Carter once wrote:
>
> ftruncate does the job and shuts-up. I like ftruncate. So it is a
> security hole. So what.
>
> So if I'm really curious about what other users are doing on my disk I
> can ftruncate all the free space and grep around looking for old dirt. So
> what. Its my disk and as Pournelle's law says, "One user, one (at
> least) CPU." People are too paranoid. If someone hacks into my machine
> and does the same to me, well, he will discover spying is the most
> boring job in the world and go home and take up street sweeping. I
> _luv_ Linux.
>

This works only on MS-DOG (that needs an lseek and a one-byte write to
extend files anyway). Linux will not allocate blocks immediatelly on
ftruncate. It will pretend that these unallocated holes are all-'\0' and
sets the remainder of a block to 0 when you do try to write it.

Did anyone check NT?

> So its not portable.
>
> True. From various other messages I have recieved and from notes in
> /usr/src/linux/mm/mmap.c there are a lot of nonportable things going
> on.
>

It's semi-portable. POSIX 4 specifies that ftruncate can expand shared
memory objects and it would be real bogus for a modern OS to implement it
differently on files. But anyway, it's pretty easy to write a function that
tries to expand a file with ftruncate one time and if it doesn't work switches
to lseek+1 byte write.
--
_. _ .
(_ ,_ _ , . / ` _ _L | Email: Oleg Kibirev <snowcat@netgate.net>
._)| U(_)\/\/ \_,(_L/L | Visit http://math.math.CSUFresno.EDU/~oleg/math.html
------------------------' to get my programs + PGP public key

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.043 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site