[17173] in bugtraq
Re: Shred v1.0 Fix
daemon@ATHENA.MIT.EDU (Chiaki Ishikawa)
Thu Oct 12 13:52:27 2000
Message-Id: <200010121330.WAA23684@sparc18.personal-media.co.jp>
Date: Thu, 12 Oct 2000 22:30:56 +0900
Reply-To: Chiaki Ishikawa <Chiaki.Ishikawa@PERSONAL-MEDIA.CO.JP>
From: Chiaki Ishikawa <Chiaki.Ishikawa@PERSONAL-MEDIA.CO.JP>
X-To: Jeff.Harlan@MAIL.SPRINT.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <39E4B958.1A572CFE@mail.sprint.com> (Jeff.Harlan@MAIL.SPRINT.COM)
X-PMC-CI-e-mail-id: 13785
Hi,
Looking at the fix, I have some comments.
Shouldn't we check
- the return value of fwrite() [Yes, I am paranoia.],
- the return value of unlink() [ ditto ]
- the return value of fopen in filesize(),
(Since we call filesize() from overwrite() in which
fopen() for the file in question is done anyway,
we might check the filesize in overwrite() AFTER
obtaining the fopen() without requiring
filesize() to fopen/fclose. Or we just pass
the fp instead of the filename...)
Should we not
- abort if fstat() in filesize somehow failed [something is
really screwed up if so.]
- warn the user just in case the remaining link count
will NOT be zero and the overwritten file
is still referenced somehow under a different name.
Just a thought.
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
