IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
----------------------------------------------------------
In rare cases, Samba 3.0.25b shows directory contents at the wrong
position in the file tree when displaying a subdirectory of a DFS link.
The problem occurs whenever Windows XP asks for a DFS referral for a
subdirectory of a DFS link with a trailing backslash.
Windows does not do this very often, but we saw it several times per day
on our central DFS server.
smbd/msdfs.c, dfs_path_lookup() does the following with the requested
path:
- in line 390, the local copy 'localpath' is 'unix_convert'ed; the
trailing backslash is removed inside unix_convert
- in lines 417-20, 'dfspath' (another copy of the requested path) is
mangled another way without removing trailing backslashes
That's why the following loop (lines 435-461) that is meant to
synchronously cut off the last path component from both strings until it
comes to a DFS link, does not handle both strings the same. When the
original path ended with a backslash, 'canon_dfspath' has always one
component more than 'localpath', so that *consumedcntp gets too big in
line 446. This value is reported to the client.
----------------------------------------------------------
Bug #4860.
Jeremy.
(This used to be commit 42d1c6713a56197ca8dfebf74eb0d483102148f7)
why check_path_syntax should not be able to run in-line. The destination
pointer either walks side by side with the source pointer or is
decremented. So as far as I can see s>=d is true throughout the whole
routine.
Jeremy, I'm checking this only into 3_0 for now. Please review and ack
or directly merge this to 3_0_26.
Thanks,
Volker
(This used to be commit 34a13c82a3b72d6900614b57c58fbaefeeca8fa7)
"host msdfs = true" to be set in the [global] section
and allow Vista to see shares with "msdfs root = yes"
and "msdfs root = no" off the same server. Down
to an error message really :-).
Jeremy.
(This used to be commit 1a0f69bb21fd03a18514dfc93c84568708144e28)
which matches what samba4 has.
also fix all the callers to prevent compiler warnings
metze
(This used to be commit fa322f0cc9c26a9537ba3f0a7d4e4a25941317e7)
were not able to connect to the rewritten dfs code as
they set the dfs flag bit but then send local paths.
Now that our dfs code is a *lot* more robust in
detecting this sort of braindamage we can just
call into it directly on getting a DFS flag
and let the parser sort it out without having
to check it's actually connecting to a dfs
enabled share (I'm proud of this code :-).
Jeremy.
(This used to be commit 8c4d929c76ba56d59f651c57d1feb37d2916a436)
works from smbclient and Windows, and I am promising to
support and fix both client and server code moving forward.
Still need to test the RPC admin support but I haven't
changed that code.
Jeremy.
(This used to be commit 7a7862c01d07796ef206b255c676ad7dc2cc42fc)
pathnames. When we're working out how much we've
consumed we need to backtrack by either a '/' or '\\'
component, as both are valid separators.
Jeremy.
(This used to be commit 1722ea20db2d531f92fb18fa5783f09258727c64)
the RESOLVE_DFSPATH macros and their varients
any more. Fix reporting profile bug with all
error returns.
Jeremy.
(This used to be commit cdf0fdb1049fd68b46885cbea887dc0e595fa524)
Attached find a workaround that works for me. This is not the "correct" fix,
to me it seems our DFS referral marshalling is broken. Vista requests level 4,
we reply with level 2, and Vista seems not to like that. If we reply with
level 3 it seems more happy.
Needs more work!
Volker
(This used to be commit 4c3a9135629415086698da28596f68f7a9db9133)
This is actually an interesting case as it exposed bad code in our DFS redirect
module (that was where the bug was introduced).
Caused by our turning on dfsroot be default.
Jeremy.
(This used to be commit 5fe25588f57ee59d70a66c755dfe70312e7afd08)
The only difference between the two trees now w.r.t file
serving are the changes to smbd/open.c in this branch I need
to review.
Jeremy.
(This used to be commit f4474edf6a0c71001dbd01429ef70bafad6abd74)
* Remove "unknown" from dfs_Enum (samba4 dfs IDL updates to follow).
* When encountering an unsupported infolevel the rpc server must reply
with a dfs_info_0 structure and WERR_OK (observed from w2k3 when talking
to nt4).
Guenther
(This used to be commit f9bef1f08f7d2a4c95c28329ac73e8646f033998)
netbios aliases. Reported by Björn Jacke <bjoern@j3e.de>.
Probably needs to be in 3.0.23b (if Björn approves
of the fix).
Jeremy.
(This used to be commit e9e711fe37d9aec28b329dbfe2ad3ebfc1771825)
fact that check_path_syntax() will convert '\\' characters to '/'.
When POSIX pathnames have been selected this doesn't happen, so we
must look for the unaltered separator of '\\' instead of the modified '/'.
Stevef please check this with the CIFSFS MS-DFS code !
Jeremy
(This used to be commit 883bb398e58f54ee79160487b49b79a4774ef939)
to do the upper layer directories but this is what
everyone is waiting for....
Jeremy.
(This used to be commit 9dafb7f48ca3e7af956b0a7d1720c2546fc4cfb8)
sink by ensuring all uses of rpcstr_push are consistent
with a size_t dest size arg.
Jeremy.
(This used to be commit f65d7afe1977d9d85046732842f9643716c15088)
realloc can return NULL in one of two cases - (1) the realloc failed,
(2) realloc succeeded but the new size requested was zero, in which
case this is identical to a free() call.
The error paths dealing with these two cases should be different,
but mostly weren't. Secondly the standard idiom for dealing with
realloc when you know the new size is non-zero is the following :
tmp = realloc(p, size);
if (!tmp) {
SAFE_FREE(p);
return error;
} else {
p = tmp;
}
However, there were *many* *many* places in Samba where we were
using the old (broken) idiom of :
p = realloc(p, size)
if (!p) {
return error;
}
which will leak the memory pointed to by p on realloc fail.
This commit (hopefully) fixes all these cases by moving to
a standard idiom of :
p = SMB_REALLOC(p, size)
if (!p) {
return error;
}
Where if the realloc returns null due to the realloc failing
or size == 0 we *guarentee* that the storage pointed to by p
has been freed. This allows me to remove a lot of code that
was dealing with the standard (more verbose) method that required
a tmp pointer. This is almost always what you want. When a
realloc fails you never usually want the old memory, you
want to free it and get into your error processing asap.
For the 11 remaining cases where we really do need to keep the
old pointer I have invented the new macro SMB_REALLOC_KEEP_OLD_ON_ERROR,
which can be used as follows :
tmp = SMB_REALLOC_KEEP_OLD_ON_ERROR(p, size);
if (!tmp) {
SAFE_FREE(p);
return error;
} else {
p = tmp;
}
SMB_REALLOC_KEEP_OLD_ON_ERROR guarentees never to free the
pointer p, even on size == 0 or realloc fail. All this is
done by a hidden extra argument to Realloc(), BOOL free_old_on_error
which is set appropriately by the SMB_REALLOC and SMB_REALLOC_KEEP_OLD_ON_ERROR
macros (and their array counterparts).
It remains to be seen what this will do to our Coverity bug count :-).
Jeremy.
(This used to be commit 1d710d06a214f3f1740e80e0bffd6aab44aac2b0)
the name (must be abolute - start with /, must not end in /,
must have ./ and ../ removed). Of course for realpath resolved
paths this won't be the case but for others we need this name
to be canonicalized. This name is going into the sharemode db
for #3303 so needs to be in a normalized format.
Jeremy.
(This used to be commit 22e3300911809692b595f49e87d91e3111923e6a)
only tell at parse time from the wire if an incoming name
has wildcards or not. If it's a mangled name and we demangle
the demangled name may contain wildcard characters. Ensure
these are ignored.
Jeremy.
(This used to be commit 4cd8e2a96b98ff711905e8c6f416b22440c16062)
the 2 BOOL flags in dfs_redirect() down to one since
they both are used in essentially the same context
(from what we can tell).
Tested Win98SE, WinXP sp 1 & 2, Win2k3 sp1, and WIn2k Sp4.
All dfs operations still seem to work.
(This used to be commit 59ffacf59c98f2f8277d76ec22712e438fd40618)
We did need the special case for RESOLVE_DFSPATH
in the findfirst() code.
Jeremy, please verify I haven't broken the allow_wcard
code you added to resolve_dfs_path()
(This used to be commit 29983398e2f7f1dc609d4d981e20f594918243bb)
functions so we can funnel through some well known functions. Should help greatly with
malloc checking.
HEAD patch to follow.
Jeremy.
(This used to be commit 620f2e608f70ba92f032720c031283d295c5c06a)
