Disable SMB2 for 3.6?

[Jeremy Allison]

On Thu, Jul 07, 2011 at 04:54:23PM +0200, Volker Lendecke wrote:
> 
> On Thu, Jul 07, 2011 at 04:48:52PM +0200, Stefan (metze) Metzmacher wrote:
> > > In response to a user bug report I've discovered a deep
> > > architectural flaw in our SMB2 server: The credential
> > > handling is not cleanly done in a central place but spread
> > > out over way too many places. The symptom is that a
> > > secondary tcon happens to be called as the user who has
> > > issued the last SMB2 request, not as root as it has been
> > > done in SMB1. This breaks quite some assumptions deep inside
> > > our code. Finding such an architectural flaw at this late
> > > stage in the release process scares me to death. So I would
> > > strongly recommend that we disable compiling SMB2 in by
> > > default and only enable it as highly experimental for 3.6.0.
> > 
> > This patch should fix the problem:
> > http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=f2806cca536de82739
> 
> It might fix it, but the fact that this went undetected for
> so long makes this non-shippable IMO.

So I've been thinking about this. The reason it went undetected
for so long is that mostly it's not an issue for correctness for
the client. Most clients are single credential connections for
most of the time.

Sure, it's a mistake and has to be fixed at the top level (in
the same way as we have the AS_USER flag in SMB1), but it isn't
a "the sky is falling" bug as you're saying here.

If we control this at the top level dispatch table, as metze's
patch does (and is the same way it's done in SMB1) then I don't
think we're in worse shape than SMB1.

The underlying issue (IMHO) is that the torture suite doesn't
assume root level access to do credential control. We need a
separate set of tests that test *real* credential changing
that can only be run as root - which aren't run on every check-in,
but that senior developers on a subsystem guarentee to run as root
on their own machines on no less than a weekly basis.

How does this sound ?

Jeremy.