[PATCH] Final removal of lp_posix_pathnames() from the smbd server main code paths.

[Jeremy Allison]

On Wed, Mar 23, 2016 at 03:11:24PM -0700, Jeremy Allison wrote:
> On Thu, Mar 24, 2016 at 12:02:48AM +0200, Uri Simchoni wrote:
> > I started reviewing it, here's where I am (note the one comment):
> > >>>
> > >>> 13). Remove lp_posix_pathnames() from msdfs code.
> > >>> Last lp_posix_pathnames() in the SMB1/2/3 code paths.
> > Not sure I quite get this one - lp_posix_pathnames() is derived from a
> > protocol handshake and we're replacing it by a heuristic?
> 
> Yes, this isn't 100% compatibile with the previous
> method. But it should work well enough in real-world
> situations that it can replace it. And the the SMB2
> case for msdfs there is no protocol handshake to look
> at so I'm having to use what I have here.
> 
> For Windows clients, msdfs paths are always \\server\share\path
> and '/' isn't allowed. For POSIX clients msdfs paths
> are //server/share/path.
> 
> The only possible problem here would be if a Windows
> stream name contains a '/', then we might misinterpret
> the path as posix.
> 
> Remember however this is only being looked at in
> a client error case (I think it was WindowsXP
> that did this) where it marked a local incoming
> path as DFS.

Just checked carefully - the strchr_m(temp,'/')
check is only being done in the allow_broken_path
case - and this is set from :

!conn->sconn->using_smb2

in both places this is called (in filename.c
and trans2.c). Which essentially means it's
a "if SMB1 only" flag.

If you like I could replace the strchr_m(temp,'/')
back with an lp_posix_pathnames() call plus a
comment explaining it as it'll never fire in the SMB2+ case.

I'd rather not though, as I really want to get
away from supporting these old bugs if I can
help it.

Let me know if you want that before giving your
rb+.

Jeremy.