lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: reiser4 plugins
    From
    Date
    On Sun, 26 Jun 2005 23:10:43 EDT, Hubert Chan said:
    > On Sun, 26 Jun 2005 20:40:29 -0400, Valdis.Kletnieks@vt.edu said:

    > > Oh, I'm waiting for the fun the first time somebody deploys a plugin
    > > that has similar semantics to 'chmod g+s dirname/' ;)

    (You *did* notice it was set-GID of a *directory* not an executable file,
    right?)

    > Reiser4 plugins have to be compiled into the kernel. (They're not
    > plugins in the sense that most people use that word.) And any admin who
    > would compile that kind of plugin into the kernel needs to have his head

    Oh? You saying that it *wont* be permitted for a user to say:

    mkdir $HOME/zipped
    chattr "files under here are ZIP files" $HOME/zipped

    and instead you have to do that chattr by hand for *every* *single* zip file?

    Or "files on this filesystem are encrypted by default"?

    I suspect that this sort of thing is going to be one of the *first* things
    that will get created, and any admin who tries to sell this idea to the users
    *without* that sort of functionality will be handed their head.

    Or, if "that type of plugin.. needs to have their head examimed", I suggest
    that you go to your kernel source tree, find fs/ext3/ialloc.c, and this code
    in ext3_new_inode():

    if (test_opt (sb, GRPID))
    inode->i_gid = dir->i_gid;
    else if (dir->i_mode & S_ISGID) {
    inode->i_gid = dir->i_gid;
    if (S_ISDIR(mode))
    mode |= S_ISGID;
    } else
    inode->i_gid = current->fsgid;

    and #ifdef out all but the last line, and see if anything breaks. ;)

    > examined. Not to mention that plugins must first go through Hans and/or
    > Linus before they can get included into the kernel.
    >
    > The kernel defines the set of plugins available to the user. The user
    > selects (to a certain degree) which plugins to use.

    The point you missed was that plugins *will* have interactions, and as
    the guys who are working on a stacker for LSM modules have found out the
    hard way, trying to deal with the composition of functions is fiendishly
    difficult.

    And notice that it doesn't *have* to be quite so obvious - how about if a
    user creates a directory $HOME/zipped/ and flags it as "anything under here
    is a zipped file".

    Now throw in multiple users and CPU limits. User A enters that directory and
    references everything, causing the buffer cache to get filled up. While there,
    A makes changes, so the pages are dirty - "for i in */*; do echo " " >> $i; done"
    would do the job... User B now does something that causes a writeback of one
    of those buffer cache pages.

    A) What process currently gets ticked for the CPU and I/O for the writeback?

    B) In your model, who will get ticked for the resources?

    C) Will the users riot? (Note that you can't win here - currently, the "price"
    of writing back A's and B's pages are about equal. However, if A gets dinked
    for an expensive writeback due to B's process, A will get miffed. If B gets
    charge for an expensive writeback of A's, B will get miffed. If you say "screw it"
    and bill it to a kernel thread, the bean counters will get miffed... ;)
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-06-27 07:08    [W:4.288 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site