Re: securety related question...

* Erika Pacholleck <[email protected]> [2002-10-08 09:26]:
> [08.10.2002] Richard Lightman <-- :
> > I do not follow this bit. You cannot assume a file has gone just
> > because you deleted it. Try this:
> > 
> > cd /var/tmp
> > seq 1000 >a
> > cat a | while read i; do echo $i; sleep 1; done
> > # on another terminal:
> > cd /var/tmp
> > rm a
> > ls
> 
> Your `ls` shows no file present here, so the file has really gone.
> But `rm` is only one way to delete a file, there are more powerful
> commands for destruction if I really want to.
> 
rm breaks the link between the name /var/tmp/a and the inode, but the
inode and the contents of the file are still on the disk until the last
file descriptor is closed. Here is a better example, that cannot be
explained by buffering:

cd /var/tmp
dd if=/dev/urandom of=a bs=1048576 count=256
# I have only 128M of memory, so this cannot all be in cache.
od a
# On an other terminal:
cd /var/tmp
df
rm a
# od is still converting the file to octal
df
# After od has stopped
df

Here is what df has to say about /var/tmp each time:

Filesystem           1k-blocks      Used Available Use% Mounted on
var_tmp                2048000    262144   1785856  13% /var/tmp
var_tmp                2048000    262144   1785856  13% /var/tmp
var_tmp                2048000         0   2048000   0% /var/tmp


Richard
-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message