null session %U expansion (patch)

[Jeremy Allison]

thwartedefforts at wonky.org wrote:
> 
> On Fri, 30 October 1998, Luke Kenneth Casson Leighton wrote:
> > therefore, if we refuse anonymous connections, then clients will
> > "revalidate" with a non-anonymous connection (usr, pass, domain)
> > immediately, and _then_ do a netwkstagetinfo call, and we will be in a
> > position to respond correctly.
> >
> > can we add a "restrict anonymous" option to refuse all null session
> > connections, which i believe will fix this problem once and for all: we've
> > been over and over this for approximately eighteen months, it keeps coming
> > up.
> 
> That sounds like exactly what is needed, assuming that the Windows clients will do the revalidate when the anonymous connection is denied.  I think I can whip this up (should it be done higher up in the call stack than in reply_sesssetup_and_X?).
> 


Unfortunately this would break browse mastering and password changes. Both
Browse synchronisation and password changing are done via an anonymous
connection.

The process that does this (browse mastering) cannot revalidate as
it doesn't have a user context to revalidate as. Look at
the browse sync code in nmbd to see what really happens.
On NT the equivalent of this code is done as the user MACHINE\System.

The reason this keeps coming up is that it's a *Microsoft*
bug that they see no profit in fixing as it only affects
Samba servers - NT doesn't change the resource list on a per
user basis.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------