Re: reiser4 plugins

[Valdis.Kletnieks@vt.edu]

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... ;)

Attachment: pgpUfxkUBUCbP.pgp
Description: PGP signature