I have proposed this filesystem at http://lkml.org/lkml/2004/11/1/48 .
In short, the filesystem I'm developing is a trivial device filesystem
that provides protection mechanism against tampering.
Reasons I don't use devfs/udev or fuse or LSM for /dev are:
The devfs/udev don't provide protection mechanism against tampering.
I don't know implementation that can enforce filename and it's attributes.
Label based access control like SELinux doesn't distinguish
/dev/sda1 and /dev/sda2, do they?
If a process who is permitted to unlink and create /dev/sda1 and /dev/sda2 is cracked,
who can ensure that /dev/sda1 is block-8-1 and /dev/sda2 is block-8-2?
A situation /dev/sda1 is block-8-2 and /dev/sda2 is block-8-1 can happen.
/dev has to be valid throughout the lifetime of system
(i.e. from /sbin/init till power failure).
Filesystems using fuse will freeze when a system starts /usr/bin/killall at shutdown script,
where it is too early to stop working of /dev partition.
LSM is used by SELinux, thus there is unlikely chance to call my module
to validate a device file's filename and it's attributes.
The latest snapshot (which is not following codingstyle) is at
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/trunk/1.5.x/ccs-patch/include...http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/trunk/1.5.x/ccs-patch/fs/syao...
If there is a chance for inclusion into kernel.org kernel, I'm willing to fix codingstyle and submit immediately.
Thank you.
-
