On Sun, Jul 23, 2000 at 11:35:11AM +0200, Alexander Langer wrote:
> Thus spake Tobias Weingartner (weingart@natasha.tepid.org):
> 
> > > > 4) "truncate file" should mean truncate to zero.
> > > No, that's a security risk.
> > Care to elaborate?!?  How is this any different than
> > cp /dev/null file?  Why would it be a security risk?

> Well, I meant because of the following:
> truncate(1) will be often used in scripts.

> If you do something like
> /usr/bin/truncate ${size} ${file} and $size is empty, it will truncate
> the file to 0, even if you wanted it to raise it by 100MB or similar.
> This won't happen with rm, which also deletes content, since the
> syntax for rm doesn't require to args.

As opposed to getting /usr/bin/truncate 100 ${file} mistakenly, where
you wanted to raise the file size to 100MB ?

How is this noticeably different ?

In my mind, both constitute `programming errors', not `security risks'.

If you want to protect against that, maybe you should consider an option
to truncate file sizes only upwards ?
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'