VFS modules proposed design - WAS Re: Moving 8.3 filenames into VFS - WAS Re: meeting with SUGJ

[Michael H Buselli]

Michael Gerdts said:

> > 	I remember discussing this with Tim, and thought he changed
> > 	to a global to allow this...
> 
> I don't know how changing it from a share to a global parameter would help.

I concur, but I've lost some of the context so that may be why I'm
confused here.

> I am not looking at the code right now, but from looking at it between
> 2.2.0 and 2.2.1, it looked like the way it was implemented, you could only
> have one module handle each call.  When VFS is compiled in you get a list
> of functions defined in default_vfs_ops as your operations.  The default
> ones behave the same as if you were not using VFS.

Currently implemented--true.  The proposed change would replace the
default_vfs_ops external global variable as referenced inside of the VFS
module with a vfs_ops pointer passed in with vfs_init().

>  The structure vfs_ops
> is initialized with pointers to functions for default_vfs_ops.  If you load
> a module that does something special with open(), vfs_ops->open gets
> changed to be a pointer to the open() call in the new module.  That is,
> vfs_ops->open can only reference one open call.
> 
> What would be needed is a list (or array, or similar) of functions that are
> called for each operation.  That is:
> 
> 	vfs_ops->open = { vfs_virus->open, audit->open, NULL };
> 
> This brings up an interesting question for stackable VFS modules... how do
> you handle stacked calls that change state?  That is, if you have a virus
> checking open() and an auditing open(), which one should really do the
> open?  If it is the first one, does it call the open before or after the
> second one is called?  How does each module know whether it is supposed to
> really do the open or just be sure that it is OK?

You're not thinking of how to implement these correctly, and that's why
you're confused on the issue of how it would work.  You don't use a list
or an array, and neither open() call knows the other exists.  Each
open() call knows that there is a "lower" open() call that it calls for
the actual open, or so it thinks.  Underneath all these open() calls is
Samba's vfswrap_open(), which actually does any REAL open() that needs
to be done unless you have a VFS module somewhere in there that
intercepts that REAL open() from happening by not calling its next lower
layer open().

Example:  stacking virus_check_open() over audit_open() will cause
virus_check_open() to be called by Samba.  Function virus_check_open()
would then call its "lower" open() call, which is audit_open() in this
case, although virus_check_open() doesn't know what function it's really
calling--it just has a function pointer to another open() call.  Then
audit_open() will call its "lower" open() function, which in this case
is the Samba provided vfswrap_open() function.  Again, audit_open()
doesn't know what open() call it's making--it just has a function
pointer to another open() call.

You have to think about what order you want to stack your VFS modules.
If you stack virus_check on top of audit, then your audit logs will show
the activities of the virus checking caused by actions of your users,
and not the actual actions of your users.  Maybe you want that, but you
are probably wanting to monitor user activity with an audit log, so you
would stack the audit VFS module on top of the virus check module.

I hope that makes sense, and I hope that the Samba core team is in
agreement on how this would work.

--
Michael H. Buselli
Senior Network Systems Specialist            Abbott Laboratories
Email: busellim at pprd.abbott.com              D472/AP9A-L20
Phone: 847-935-4624                          100 Abbott Park Road
Fax: 847-935-0142                            Abbott Park, IL  60064-3500