remote gensec (was: Re: [PATCH] remove ntlm_auth4)

[Simo]

On Sat, 2016-11-26 at 08:03 +1300, Andrew Bartlett wrote:
> On Fri, 2016-11-25 at 10:45 +0100, Volker Lendecke wrote:
> > 
> >  
> > This patch was the start of me looking at re-working ntlm_auth3
> > such
> > that more logic is happening in winbind. While there my usual
> > approach
> > is to also look left and right trying to understand the
> > environment.
> > One thing that annoyed me was that with emacs tags I always ended
> > up
> > in the source4 version of ntlm_auth. So I asked myself whether that
> > is
> > still required at all and ended up with the patch proposal.
> > 
> > As re-working ntlm_auth3 is now cancelled due to the architectural
> > approach, the ntlm_auth4 removal patch is no longer on my list.
> 
> Could you do that inside the gensec layer?  The reason I ask is that
> you were wildly successful with the messaging rework because you not
> only kept largely that same external APIs and functionality like
> IRPC,
> but you unified much of the marshalling code and the transport so
> allowing much more of the code to talk to each other (like smbcontrol
> being able to ask any process for a memory dump). 
> 
> If the gensec layer had a remote module, we certainly would find
> other
> uses for such functionality, like process isolation from the secrets
> and improved async. 
> 
> (I know I've been sceptical about how well gssapi state can be moved
> between processes for the subsequent encryption, but if it works it
> would be a very interesting feature). 
> 
It works for privilege separation if you respect abstractions, look at
the interposer module stuff we have in MIT Kerberos and the GSS-Proxy
project.
If you want to do priv/sep remotization you should re-use those
interfaces and not reinvent the wheel.

Simo.