Project

General

Profile

Actions
Copy link

Bug #128

closed

cat /directory shows a (somewhat messy) list of files in a directory (even removed files)

Added by arachnist over 18 years ago. Updated about 18 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

When you create some dir, create some files in it, then remove them
and do a cat /path/to/that/dir you get a messed-up list of files along
with the removed ones, in some situations this might be considered a
security threat. The following script ilustrates what i mean:

#!/bin/sh
mkdir somedir
for i in file1 file2 file3 file4; do
touch somedir/$i;
done
echo contents of somedir:
ls somedir
for i in file1 file2 file3 file4; do
rm somedir/$i;
done;
echo contents of somedir:
ls somedir
echo that shouldn\'t be here
cat somedir

Expected results:
nothing or a ls-like list of files

What i got:

contents of somedir:
file1 file2 file3 file4
contents of somedir:
that shouldn't be here
2

.Yô..3
      file1$ÁJ
             file2$ÁM
                    file3$ÁN
Actions
Copy link
 #1

Updated by dillon over 18 years ago

:When you create some dir, create some files in it, then remove them
:and do a cat /path/to/that/dir you get a messed-up list of files along
:with the removed ones, in some situations this might be considered a
:security threat. The following script ilustrates what i mean:

It's an artifact of the way UFS stores directories.  When you
    'rm' a file, the directory entry is simply marked invalid rather
    than destroyed.  The file's data is not destroyed either unless
    you overwrite it before deleting it (e.g. with rm -P).
-Matt
Actions
Copy link
 #2

Updated by joerg over 18 years ago

On Sun, Mar 26, 2006 at 12:00:50PM +0200, Robert Sebastian Gerus wrote:

Expected results:
nothing or a ls-like list of files

Get a UNIX history book talking about the introduction of opendir ages
ago and the discussions why allowing open(2) and read(2) can be allowed
or not. In summary, you have to have read access to the directory and
file names should not store sensitive information. Other users could
have seen the file otherwise anyway.

Also keep in mind that most filesystems internally do this anyway.
To protetc against basic forensic, nothing but overwriting the directory
(which can be quite difficult :-)) helps.

Joerg

Actions
Copy link

Also available in: Atom PDF