Ideas for changes to Unix filesystem

[Lars Henrik Mathiesen]

richard at locus.com (Richard M. Mathews) writes:
>jeremy at socs.uts.edu.au (Jeremy Fitzhardinge) writes:
>>1 - a flink(char *path, int fd) system call/operation.

>>The only security problem I can think of is
>>this: it would be possible to link a file back into the filesystem into
>>a publically accessable directory after some time, even if the path to
>>the original file becomes closed.  If this were a real problem, you'd
>>have to use a utility like fuser to see what processes have what files
>>open in the closed off area.

As it is now, you have to use a utility like ncheck to see what hard
links there are lying around.

>Say there is a
>file protected by directory permissions which some setuid/setgid program
>lets you look at under controlled circumstances.  Your program can now
>create a name for the file not protected by the directory and reopen the
>file with more flexibility.  This may be far fetched, but it should be
>considered.

As it is now, if you get an open file descriptor for a file, you can
copy it anywhere you like; if you want to track changes, fstat every
second and re-copy as needed. This would not be a new hole, it would
just be easier to use.

>Combined with problems like only being able to link it to a name in the
>correct file system, I think this idea needs some work.

With the obvious implementation of flink, the sequence
	fd = open("foo", mode);
	flink(fd, "bar");
will have _exactly_ the same effect as, and fail in the same cases as,
	fd = open("foo", mode);
	link("foo", "bar");
This includes making a hard link to /dev/tty?? or a FIFO inode if
that's what fd was opened on. (Under Sun licensed NFS, and 4.3 BSD.)

If I could think of something to use it for, I'd add it to the kernel
tonight. (Except we also have Suns, so that'd be one more
incompatibility. Or maybe they'd let us buy source if we said we
wanted to ``experiment with kernel extensions''?)

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn at diku.dk