security: VFS copy() skips limits on overwrite, rename() overwrites dirs (TM-DOS-047, TM-DOS-048)

[chaliy]

Summary

Two VFS semantic bugs in InMemoryFs:

TM-DOS-047: copy() at fs/memory.rs:1176-1179 only calls check_write_limits() when is_new=true. Overwriting a small file with a large one skips the size check entirely, allowing total VFS bytes to exceed max_total_bytes.

TM-DOS-048: rename() at fs/memory.rs:1136-1153 uses HashMap::insert which silently overwrites any entry type. rename(file, dir) replaces a directory entry with a file, orphaning all children (they remain in the HashMap but their parent is now a file, not a directory).

Impact — MEDIUM

• TM-DOS-047: VFS size limits can be exceeded via copy-overwrite
• TM-DOS-048: VFS corruption — orphaned entries consume memory but are unreachable through normal path traversal

Recommended fix

copy(): Always call check_write_limits(), accounting for the size delta when overwriting:

let delta = entry_size.saturating_sub(existing_size);
self.check_write_limits(&entries, &to, delta as usize)?;

rename(): Check destination type — reject file-over-directory per POSIX:

if matches!(entries.get(&to), Some(FsEntry::Directory { .. })) {
    return Err(IoError::new(ErrorKind::Other, "cannot rename file over directory"));
}

Tests

Regression tests (currently #[ignore]):

• security_audit_copy_enforces_limit_on_overwrite
• security_audit_rename_rejects_file_over_dir

Cross-references

• Threat model: TM-DOS-047, TM-DOS-048
• PR: test(security): deep security audit with regression tests #487