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

[Uri Simchoni]

On 03/25/2016 12:58 AM, Jeremy Allison wrote:
> On Thu, Mar 24, 2016 at 02:35:00PM +0200, Uri Simchoni wrote:
>> Done!
>>
>> To summarize:
>> - I have a couple of cosmetic comments on #5, but it's otherwise RB+ me.
>> - Cannot ack #13 - seems like a "product decision" because it changes
>> behavior no to support old buggy clients, plus if we do change behavior
>> it seems we can delete the "buggy client support code" rather than
>> change it. (see separate message on thread)
>>
>> Otherwise RB+ me.
> 
> Ok, my 'evil' plan to fix #13 failed as there's no
> way from the rpc pipe serving DFS code to know if
> we got the request over SMB1 or SMB2+, so here
> is my proposed alternative solution (attached).
> 
> It does change the separator detection to remove
> the lp_posix_pathname() call in DFS, so it is
> a change in server behavior, but no clients will
> notice the difference as they don't send requests
> that would differentiate (see below).
> 
> In the old code, in order to get POSIX pathname
> parsing of a DFS path a client has to select POSIX
> over SMB1, then send a pathname starting with '/'
> (note I'm ignoring the broken SMB1-only DFS path case,
> which I've left using lp_posix_pathnames(), so no
> change there).
> 
> But all clients either send DFS pathnames with '/'
> separators after selecting unix extensions
> (see cli_dfs_make_full_path() for details)
> or send pathnames with '\' separators
> without selecting unix extensions.
> 
> The only case where this difference could be
> detected is if a client didn't select unix extensions
> and then sends a pathname starting with '/', but
> also containing '\' separators and I'm confident
> no clients do this (and even if they did all
> that would happen is they'd get a successful
> DFS parse which would have previously failed).
> 
> Please review and push if happy !
> 
> Cheers,
> 
> 	Jeremy.
> 

Pushed!

>From what I understand the change in behavior is only if the client is
non-posix:
- before change, anything besides '\\' at the beginning of the path is
considered broken client sending local path, and only '\\' is expected
as path separator.
- after change, '/' is also allowed and not considered a local path (at
least initially - it may cause parsing to fail later).

The actual buggy clients that we take care of send local paths, that is
paths that begin with neither '/' nor '\\', and therefore are not
affected by the change.

Thanks,
Uri.