se-samba

[tridge at samba.org]

Russell,

One thing to be careful of is to distinguish the right design for a
se-linux enabled Samba in Samba3 and Samba4. The design of Samba3 is
quite different from Samba4, and the approach taken needs to be
correspondingly different. The design that Luke proposes is closely
tied to Samba3, as that is what he is familiar with. Samba-tng uses
the same basic design for file sharing as Samba3, as it is based on
the same code.

The main features of the Samba4 design that are relevant to you are:

 - backend isolation. Samba4 uses a "NTVFS" layer, which takes the
   place of the old VFS layer in Samba3. All POSIX/Unix filesystem
   assumptions are isolated into the backends behind this layer, so
   for example uid_t and gid_t will only appear in these backends. 

 - The core code makes no calls to seteuid() at all. So if you write
   your own NTVFS backend you can choose not to use seteuid() if you
   don't want to. 

 - async backends. On a per-call basis the backends can choose to
   answer synchronously or asynchronously. This allows you
   considerable flexibility in how you dispatch operations. It also
   solves the NT threads problem that Luke mentioned.

 - flexible process models. Samba4 comes with 3 process models,
   selectable at runtime, and you could potentially add another
   process model if you want to. The default models are "single" (with
   everything in one process), "standard" (a process per connection),
   and "thread" (a posix thread per connection). The best choice is to
   make your backend work with any process model, but you could tie it
   to a particular backend if you need to.

 - support for remote backends. A backend doesn't need to store its
   files on the local computer, the interface is designed to allow for
   the storage to be remote. This makes inter-process schemes like you
   are thinking of for se-linux much easier (two of the existing
   backends are remote backends).

While you could target a se-linux enabled Samba at Samba3, I don't
think it would be a good idea. The changes required would be quite
substantial, and I would expect that Jerry (as release manager) would
be unlikely to accept them into a stable release version unless you
can in some way isolate the changes very cleanly (which I think will
be difficult). Major changes of this type are better suited to the
next major version, which is Samba4.

The bad news is that Samba4 is still a work in progress. There is
enough done for you to start writing your backend now if you want to,
but you don't have a lot of examples to work with, especially as the
main POSIX backend isn't done yet. If you are willing to wait a couple
of months then you'll probably find it a bit easier to work on.

Cheers, Tridge