On 10/07/2011 10:22 AM, Darrick J. Wong wrote:

On Fri, Oct 07, 2011 at 12:11:03AM -0700, Allison Henderson wrote:

quoted

This patch zeros or randomizes a files directory entry when a file

<snip>

quoted

@@ -1669,7 +1672,38 @@ static int ext4_delete_entry(handle_t *handle,
  				de->inode = 0;
  			dir->i_version++;
  			BUFFER_TRACE(bh, "call ext4_handle_dirty_metadata");
-			err = ext4_handle_dirty_metadata(handle, dir, bh);
+
+			/*
+			 * If the secure remove flag is on, zero
+			 * or randomize the entry and write it out
+			 * to the disk
+			 */
+			if (flags&  EXT4_DEL_ENTRY_ZERO) {
+				memset(de->name, 0x00, de->name_len);
+				de->file_type = 0;
+			} else if (flags&  EXT4_DEL_ENTRY_RAND) {
+				get_random_bytes(de->name, de->name_len);
+				get_random_bytes(&(de->file_type),
+					sizeof(de->file_type));

Seeing as name_len and file_type precede name, you could probably reduce this
to one call that zaps all three.  Same for the zero-out case.

Also you might want to make both of these name-erasing calls zap the space
between the end of the name and the end of the record, just in case there's old
filename component still lurking in that space.  (Yes, paranoia...)

Alrighty, sounds good to me.

quoted

+			}
+
+			if (flags&  EXT4_DEL_ENTRY_ZERO ||
+				flags&  EXT4_DEL_ENTRY_RAND) {
+
+				set_buffer_dirty(bh);
+				sync_dirty_buffer(bh);
+				if (buffer_req(bh)&&  !buffer_uptodate(bh)) {
+					es->s_last_error_block =
+						cpu_to_le64(bh->b_blocknr);
+					ext4_error_inode(dir, __func__,
+					   __LINE__, bh->b_blocknr,
+					   "IO error syncing itable block");

itable?

Sorry, I borrowed this snippet from another area of code and forgot to update the error message.  Will fix :)

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html