lkml.org 
[lkml]   [2007]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2.6.24-rc1]EXPORT_SYMBOL(__set_page_dirty_no_writeback);
    From
    Date
    Hello.

    Arjan van de Ven wrote:
    > when will you post this filesystem for inclusion into kernel.org kernel?
    > (and please really consider posting the patch together with that patch)
    > (also, if you can give a pointer to the source code of this filesystem
    > you might even get early code review)

    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/linux/syaoran.h?content-type=text%2Fplain&rev=588&root=tomoyo
    http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/trunk/1.5.x/ccs-patch/fs/syaoran_2.6.c?content-type=text%2Fplain&rev=614&root=tomoyo

    If there is a chance for inclusion into kernel.org kernel, I'm willing to fix codingstyle and submit immediately.

    Thank you.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-25 14:19    [W:0.025 / U:90.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site