[Pkg-samba-maint] Bug#440451: Bug#440451: Bug#440451: dfs_redirect causes NT_STATUS_OBJECT_NAME_NOT_FOUND

[Marcin Owsiany]

On Sun, Sep 16, 2007 at 04:57:18PM +0200, Christian Perrier wrote:
> I just tried to reproduced that bug today with no luck, either on an
> etch system (3.0.24-6etch4) or on an up-to-date unstable system
> (3.0.26-1).

What does the log show in your case?

Also, please try creating group "pub" and testing with that instead of
"nogroup". Nobody does not need to belong to it (it didn't in my case).


I had a look at smbd/msdfs.c and there is the following code in there:

|BOOL dfs_redirect( pstring pathname, connection_struct *conn, BOOL search_wcard_flag )
|{
|        struct dfs_path dp;
|
|        if (!conn || !pathname) {
|                return False;
|        }
|
|        parse_processed_dfs_path(pathname, &dp, search_wcard_flag);
|
|        /* if dfs pathname for a non-dfs share, convert to tcon-relative
|           path and return false */
|        if (!lp_msdfs_root(SNUM(conn))) {
|                pstrcpy(pathname, dp.reqpath);
|                return False;
|        }
|
|        if ( !( strequal(dp.servicename, lp_servicename(SNUM(conn)))
|                || ( strequal(dp.servicename, HOMES_NAME)
|                     && strequal(lp_servicename(SNUM(conn)), get_current_username()) )) )
|        {
|                return False;
|        }
|
|        if (resolve_dfs_path(NULL, pathname, &dp, conn, search_wcard_flag,
|                             NULL, NULL, NULL, NULL)) {
|                DEBUG(3,("dfs_redirect: Redirecting %s\n", pathname));
|                return True;
|        } else {
|                DEBUG(3,("dfs_redirect: Not redirecting %s.\n", pathname));
|
|                /* Form non-dfs tcon-relative path */
|                pstrcpy(pathname, dp.reqpath);
|                DEBUG(3,("dfs_redirect: Path converted to non-dfs path %s\n", pathname));
|                return False;
|        }
| [...]

dfs_redirect is called by RESOLVE_DFSPATH_WCARD() if msdfs is enabled (it is by
default) from within reply_unlink.

In my test, in the failing case, the execution path makes it as far as one of
the DEBUG() calls after resolve_dfs_path(). In the other (successful) case,
dfs_redirect() must have exited earlier, as there are no debug messages from
this function.

This suggests that parse_processed_dfs_path(), which does a lot of scary string
manipulation somehow sets "struct dfs_path dp" in the failing case such that
the strequal checks which are done right before resolve_dfs_path() do not case
a return from dfs_redirect().

-- 
Marcin Owsiany <porridge at debian.org>             http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216