Subject: Re: CRITICAL ** Holes in default cron jobs ** CRITICAL
To: None <>
From: Jim Reid <>
List: tech-kern
Date: 01/02/1997 11:35:53
>>>>> "Stefan" == Stefan Grefen <> writes:

    Stefan> This race can be detected in usermode by checking the
    Stefan> directory's st_mtimespec, st_ctimespec and the files
    Stefan> inode-number against the one in the stat-buffer.  If the
    Stefan> inode-number matches and the timespecs of the directory
    Stefan> didn't change it's still the same file. If not rescan the
    Stefan> directory.

But you can diddle this with utimes or fiddling with the TOD clock.

    Stefan> A more convenient way to do that, would be to return the
    Stefan> inode-generationnumber in the result of readdir().

That introduces other security holes. Once the generation number is
known - I know BSD fills it in for the stat struct - you can forge NFS
file handles.

    Stefan> The goal should be to enhance the definition of an inode
    Stefan> (which is included in the readdir() result) to uniqly
    Stefan> define a file (on the disk AND in the time-domain).  This
    Stefan> can easily be done by adding the msec time at the time of
    Stefan> creation to the inode (plus workarounds for reboots,
    Stefan> broken clocks etc.) and a machine or disk ID to avoid
    Stefan> problems moving disks, between machines.

This is getting very, very silly. There's nothing wrong with the way
an inode is just now. LEAVE IT ALONE.

Also, you don't seem to have thought through your suggestion. [inodes
don't have a creation time, unless you consider the 4.4BSD di_gen
field of a dinode as such.] What do you do about files restored from
backups: will they get the creation time the backup was restored or the
one when the original file was created?

    Stefan> Than add operations that can work on this handles (either
    Stefan> by using a a NOIO open or be different/additional
    Stefan> arguments to existing systemcalls).  A very elegant
    Stefan> solution would be a unique-inode-filesystem.  You could
    Stefan> even use sh,ls and rm than to securely remove files: (lets
    Stefan> assume -I means display unique-inode).

    Stefan> This would only remove the file /tmp/xx which existed at
    Stefan> the time of the ls.  Regardless if it is issued
    Stefan> immediately or a year after the ls.

If you want that sort of functionality, put it in the applications
which need it. It doesn't belong in the filesystem. Once upon a time
UNIX was a simple OS which just did what it was told. Some people seem
to have lost sight of that stunningly elegant concept.