features in samba 3.alpha (VFS)

[Andrew Bartlett]

David Collier-Brown wrote:
> 
>  On Sun, 2 Dec 2001, Tim Potter wrote:
> [assuming I've got the quoting right!]
> > We didn't progress past the argument stage of stackable vfs modules.  (-:
> > I think the consensus was that it was too hard to figure out the
> > semantics of how it would work.
> 
>         Well, in principle they're stackable, but we
>         don't have a mechanism for stacking them!
>         Tim and I were the discussants, when trying
>         to figure out how to document them.
> 
> David Lee <t.d.lee at durham.ac.uk> wrote
> > Semantics?  Might a useful starting-point be the model used by PAM
> > (Pluggable Authentication Modules) with its "requisite, required,
> > optional, sufficient" configuration options etc.  (Sure, we may well find
> > reasons why that is insufficient, but it may at least get our thinking
> > started...)
> 
>         And that sounds good... the equivalents are something like:
>         requisite       you must pass through this layer
>         required        ?
>         optional        you need not go here
>         sufficient      you don't need any more layers
> 
>         In a stacking architecture, this sounds  more than
>          sufficient...
> 
> > So I'd like to encourage those members of the Samba team who are thinking
> > about VFS to consider whether we can, somehow, support multiple VFS layers
> > per share.

In my mind, creating a stacking VFS is quite simple:

Each module both provides and accepts a VFS_OPTS structure.  The one it
provides implements the operations it supports, and the one it accpets
is used when it needs to conduct an operation.

For example, a module doing a virus scan could implement the 'open()'
VFS op, by calling the open() in the supplied next_ops structure, while
doing a virus-scan in the middle.  

However, an SQL database VFS doing an 'open()' wouldn't call down the
chain, becouse it wouldn't make any sense.

The default vaule for ths next_ops would be the default_ops structure,
and the functions in this would be extended to do the same - call the
next struture's functions.  If the next strucutre is itself - then do
the normal Samba default ops.

This gives you a nice simple interface - all the modules are just a
list.

You could go the full pam-like interface, but I don't see how it helps
much - the ability to be 'sufficient' implies the module signling back
things that never change - why not just keep them in the code?  
(Specifing that an SQL module must pass-though its ops to another module
doesn't make sense, and specifing the virus scanner as the final module
doesn't either).

Just my two bobs worth

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net