[PATCH] Final removal of lp_posix_pathnames() from the smbd server main code paths.
jra at samba.org
Thu Mar 24 22:58:13 UTC 2016
On Thu, Mar 24, 2016 at 02:35:00PM +0200, Uri Simchoni wrote:
> 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
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 !
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1933 bytes
Desc: not available
More information about the samba-technical