Indirect leak of 232 byte(s) in 1 object(s) allocated from:
#0 0x7fc44b971c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7fc44a2fe7b0 in __talloc_with_prefix ../../lib/talloc/talloc.c:782
#2 0x7fc44a2fe7b0 in __talloc ../../lib/talloc/talloc.c:824
#3 0x7fc44a2fe7b0 in _talloc_named_const ../../lib/talloc/talloc.c:981
#4 0x7fc44a2fe7b0 in _talloc_array ../../lib/talloc/talloc.c:2764
#5 0x7fc44a1239bc in str_list_make_v3 ../../lib/util/util_strlist_v3.c:58
#6 0x7fc44a123e3b in str_list_make_v3_const ../../lib/util/util_strlist_v3.c:127
#7 0x7fc44b14cc1a in init_globals ../../source3/param/loadparm.c:547
#8 0x7fc44b14deef in lp_load_ex ../../source3/param/loadparm.c:3876
#9 0x7fc44b14f97c in lp_load_initial_only ../../source3/param/loadparm.c:4025
#10 0x7fc44b479235 in cmdline_messaging_context ../../source3/lib/cmdline_contexts.c:34
#11 0x557cf59d642c in process_options ../../source3/utils/smbpasswd.c:200
#12 0x557cf59d642c in main ../../source3/utils/smbpasswd.c:633
#13 0x7fc4419f5412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com> Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sat Aug 10 20:42:39 UTC 2019 on sn-devel-184
Swen Schillig [Mon, 5 Aug 2019 09:15:59 +0000 (11:15 +0200)]
torture: fix mem leak found by ASAN (smb2_scan)
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f63e6938c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f63e615fa5c in __talloc_with_prefix ../../lib/talloc/talloc.c:782
#2 0x7f63e615fa5c in __talloc ../../lib/talloc/talloc.c:824
#3 0x7f63e615fa5c in _talloc_named_const ../../lib/talloc/talloc.c:981
#4 0x7f63e615fa5c in talloc_named_const ../../lib/talloc/talloc.c:1748
#5 0x55609e7530cf in torture_smb2_scan ../../source4/torture/smb2/scan.c:203
#6 0x7f63e2a37772 in wrap_simple_test ../../lib/torture/torture.c:633
#7 0x7f63e2a3b75e in internal_torture_run_test ../../lib/torture/torture.c:442
#8 0x7f63e2a3c543 in torture_run_tcase_restricted ../../lib/torture/torture.c:507
#9 0x7f63e2a3cdd5 in torture_run_suite_restricted ../../lib/torture/torture.c:357
#10 0x7f63e2a3cf25 in torture_run_suite_restricted ../../lib/torture/torture.c:362
#11 0x7f63e2a3d434 in torture_run_suite ../../lib/torture/torture.c:339
#12 0x55609e3a154a in run_matching ../../source4/torture/smbtorture.c:93
#13 0x55609e3a2f56 in torture_run_named_tests ../../source4/torture/smbtorture.c:143
#14 0x55609e3a699d in main ../../source4/torture/smbtorture.c:691
#15 0x7f63dad59412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x7f3c76fe5c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f3c7680df33 in __talloc_with_prefix ../../lib/talloc/talloc.c:782
#2 0x7f3c7680df33 in __talloc ../../lib/talloc/talloc.c:824
#3 0x7f3c7680df33 in _talloc_named_const ../../lib/talloc/talloc.c:981
#4 0x7f3c7680df33 in _talloc_zero ../../lib/talloc/talloc.c:2422
#5 0x7f3c7680e2a5 in _talloc_zero_array ../../lib/talloc/talloc.c:2775
#6 0x557a50d4a09f in torture_bench_treeconnect ../../source4/torture/raw/tconrate.c:165
#7 0x7f3c730e4772 in wrap_simple_test ../../lib/torture/torture.c:633
#8 0x7f3c730e875e in internal_torture_run_test ../../lib/torture/torture.c:442
#9 0x7f3c730e9543 in torture_run_tcase_restricted ../../lib/torture/torture.c:507
#10 0x7f3c730e9dd5 in torture_run_suite_restricted ../../lib/torture/torture.c:357
#11 0x7f3c730ea434 in torture_run_suite ../../lib/torture/torture.c:339
#12 0x557a50c1b54a in run_matching ../../source4/torture/smbtorture.c:93
#13 0x557a50c1cf56 in torture_run_named_tests ../../source4/torture/smbtorture.c:143
#14 0x557a50c2099d in main ../../source4/torture/smbtorture.c:691
#15 0x7f3c6b406412 in __libc_start_main (/lib64/libc.so.6+0x24412)
In case of a failing talloc_realloc(), the only reference
to the originally allocated memory is overwritten.
Instead use a temp var until success is verified.
libcli:smb: Add forward declaration for gnutls_hmac_hd_t
This file is basically included everywhere. So use a forward declaration
for gnutls_hmac_hd_t. This way we don't have to link everthing against
gnutls to get access to the header path.
Signed-off-by: Andreas Schneider <asn@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Both of these changes make the routine easier to understand for me,
less jumping around in the code to see where the values came from.
* Do the retry in a "positive" if-clause
Normally I'm a big fan of early returns, but this single retry is so
simple that to me it's easier to understand this way.
Overall, 13 lines less code. YMMV :-)
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sat Aug 10 00:07:28 UTC 2019 on sn-devel-184
I don't really have a test case, but to me a positive test for a
regular file makes more sense here than just ruling out FIFOs. While
we probably only ever hit regular files (or FIFOs), there might be
more that we catch and don't properly handle.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Volker Lendecke [Wed, 7 Aug 2019 19:37:31 +0000 (21:37 +0200)]
smbd: Make "lease" const in create_file_unixpath()
This is the one place where *lease actually got modified. We can
easily make a copy, "struct smb2_lease" is not too large, and this
case is pretty rare anyway.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Jeremy Allison [Thu, 8 Aug 2019 22:59:15 +0000 (15:59 -0700)]
s3: VFS: vfs_ceph_snapshots: Make setxattr return errno = EROFS on a shadow copy path.
smbd has no business modifying a shadow copy filesystem, it should be read-only.
Signed-off-by: Jeremy Allison <jra@samba.org> Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Aug 9 18:08:03 UTC 2019 on sn-devel-184
Volker Lendecke [Fri, 9 Aug 2019 06:02:41 +0000 (08:02 +0200)]
mdssvc: Fix the clang build
clang complains about "%lu" not to match size_t on 32-bit FreeBSD
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Fri Aug 9 07:34:05 UTC 2019 on sn-devel-184
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Aug 8 21:43:14 UTC 2019 on sn-devel-184
Ralph Boehme [Mon, 6 May 2019 12:14:26 +0000 (14:14 +0200)]
s3:mdssvc: failing the RPC request if the mdssvc policy handle is not found
Turns out macOS mdssvc doesn't fail the RPC request if the policy handle is all
zero. Also, if it fails with a non-all-zero handle, it returns a different RPC
error, namely DCERPC_NCA_S_PROTO_ERROR, not DCERPC_FAULT_CONTEXT_MISMATCH (or
rather their mapped NT_STATUS codes).
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Mon, 6 May 2019 12:11:31 +0000 (14:11 +0200)]
s3:mdssvc: the open command must work on shares with Spotlight disabled
Move the implementation of this setting down to the actual search query
processing. macOS has no notion of "spotlight = false" at the DCERPC layer and
the open request will always succeed even on all shares.
When later the client issues search requests on such shares, we ensure we use
the noindex backend.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Tue, 16 Apr 2019 17:25:09 +0000 (19:25 +0200)]
s3:mdssvc: initialize the returned share_path with the empty string
macOS returns the empty path for an unknown share. This paves the way for that
change. Currently we still fail the RPC request if the share is not known with
DCERPC_FAULT_CANT_PERFORM, but this is wrong and is going to be changed in the
next commit.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Tue, 16 Apr 2019 12:17:11 +0000 (14:17 +0200)]
s3:mdssvc: fix error handling of mdssvc RPC requests
It seems for certain error cases macOS just sends an empty response
blob. So if our mdssvc request processing fails, we should just return an empty
response blob, but not fail the mdssvc request at the DCERPC layer.
Example, passing "xxx" as sharename which does not exist at the server:
This is basically the response from macOS mdssvc for a query that yields no
results: sl_filemeta_t is empty, the CNIDs array as well.
Looking at the raw packet data, the empty sl_filemeta_t container as a size of 8
bytes which fails the following check in sl_unpack_cpx():
case SQ_CPX_TYPE_FILEMETA:
...
if (tag.size < 16) {
*boom*
}
Only tag.size=0 is invalid, tag.size=8 denotes an empty container and tag.size>=16
denotes a sl_filemeta_t container with actual content must be unpacked by
calling sl_unpack(). Note that size is always a muliple of 8.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Wed, 17 Apr 2019 14:42:20 +0000 (16:42 +0200)]
s3:wscript: enable Spotlight by default
Now that we have a no-op backend that is always available, we can compile mdssvc
by default.
The new behaviour is:
option not used Default: build mdsvc with available backends
from autodetection
--disable-spotlight Do not build mdssvc
--enable-spotlight Build mdssvc and require a real backend
(currently Tracker, in the future also Elasticsearch)
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
==> /builds/samba-team/devel/samba/samba-o3.stderr <==
In file included from /usr/include/string.h:494,
from /usr/include/bsd/string.h:30,
from ../../lib/tevent/../replace/replace.h:164,
from ../../source3/include/includes.h:23,
from ../../source3/rpc_server/mdssvc/marshalling.c:21:
In function ‘strncpy’,
inlined from ‘sl_pack_string’ at ../../source3/rpc_server/mdssvc/marshalling.c:493:2,
inlined from ‘sl_pack_loop’ at ../../source3/rpc_server/mdssvc/marshalling.c:607:13:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ output
truncated before terminating nul copying as many bytes from a string as its
length [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../source3/rpc_server/mdssvc/marshalling.c: In function ‘sl_pack_loop’:
../../source3/rpc_server/mdssvc/marshalling.c:458:8: note: length computed here
458 | len = strlen(s);
| ^~~~~~~~~
cc1: all warnings being treated as errors
Marshalled strings are not 0 terminated.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Sun, 21 Apr 2019 06:38:23 +0000 (08:38 +0200)]
unittest: workaround dependency problem in test_lib_util_modules
waf somehow screws the dependencies and the module ends up with a bunch of
missing RPC related symbols once an RPC service has special dependencies like
the mdssvc RPC service.
Ralph Boehme [Tue, 16 Apr 2019 12:04:16 +0000 (14:04 +0200)]
s3:mdssvc: supposed status field is in fact a fragment indicator
Spotted this in mdssvc response that containied many results for a search
request: if the mdssvc response blob is larger then ~32k, the server fragments
the response in 32k fragments and sets the "fragment" field to 1.
Note that mdssvc implemenets result set "fragmentation" at the result set layer,
not at the marshalled response buffer layer. Therefor mdssvc always sets this
field to 0.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Ralph Boehme [Thu, 14 Mar 2019 06:38:20 +0000 (07:38 +0100)]
s3-mdssvc: factor out Tracker backend logic
This moves all Tracker backend logic into a modularized component.
This should not result in any change in behaviour, it just paves the way
for adding additional backends. Currently the only available backend is
Gnome Tracker.
slq_destroy_send/recv is not needed anymore as the problem is solved now by
correctly checking if an async Tracker request was cancelled and we got
G_IO_ERROR_CANCELLED in tracker_con_cb() or tracker_query_cb() and avoid using
user_data in that the case.
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
registry: Free memory at the end of each loop run to prevent mem leak
Found during torture test runs with enable address-sanitizer.
Signed-off-by: Swen Schillig <swen@linux.ibm.com> Reviewed-by: Volker Lendecke <vl@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Aug 8 06:44:12 UTC 2019 on sn-devel-184
Volker Lendecke [Thu, 1 Aug 2019 12:47:41 +0000 (14:47 +0200)]
torture: SMB1 unlink needs delay for a stream's SHARING_VIOLATION
Survives against W2k12R2
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Aug 8 01:05:38 UTC 2019 on sn-devel-184
This is close to what Windows SMB1 does: Instead of waiting for the
share entry causing the SHARING_VIOLATION to disappear, retry every
200msec up to one second. Windows does it a little differently: Retry
up to 5 times. But up to one second should be close enough.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Volker Lendecke [Fri, 2 Aug 2019 09:54:11 +0000 (11:54 +0200)]
smbd: Get "req->request_time" early in create_file_default()
This is necessary for the following case:
We want to delete a file with an open stream that is not open with
FILE_SHARE_DELETE. In SMB1, we need to defer the sharing violation
reply (we don't do that right now, test to follow). However, when we
move that sharing violation delay to where it belongs, into the outer
layers, only very deep in the nested open_streams_for_delete smb1
sharing violation delay handling call we will hit the sharing
violation in the 1-second retry case. However, that
open_streams_for_delete itself is INTERNAL_OPEN_ONLY and thus not
deferred itself. This means that it will not overwrite
req->request_time at all.
Exec summary: We only have one request_time now, set it properly as
early as possible.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Volker Lendecke [Fri, 2 Aug 2019 12:33:22 +0000 (14:33 +0200)]
smbd: Do not exceed the req's max timeout in setup_poll_open()
This will become important in the next commits when the SMB1 sharing
violation delay will use this. We want to be able to reduce the
timeout to less than 200msec, see the next commits.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
smbd: Avoid exit_server() in setup_kernel_oplock_poll_open()
Failure to postpone a request is not really fatal: We just don't retry
as wanted but return an error to the client that might have resolved
itself after a few seconds. From my point of view such a spurious and
rare error, which is highly unlikely anyway does not justify to kill
that client's connection.
Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Jeremy Allison [Thu, 1 Aug 2019 20:40:43 +0000 (13:40 -0700)]
s3: VFS: Make setxattr return errno = EROFS on a shadow copy path.
smbd has no business modifying a shadow copy filesystem, it should be read-only.
Signed-off-by: Jeremy Allison <jra@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Aug 7 17:59:25 UTC 2019 on sn-devel-184
Samuel Cabrero [Tue, 6 Aug 2019 16:21:12 +0000 (18:21 +0200)]
s4:librpc/rpc: Use generic roh_connect_channel_send/recv
The HTTP connection code is common to in and out channels.
Signed-off-by: Samuel Cabrero <scabrero@suse.de> Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Aug 7 14:12:40 UTC 2019 on sn-devel-184
Ralph Boehme [Wed, 3 Apr 2019 12:33:12 +0000 (14:33 +0200)]
s4:lib/http: add support for http POST
Even though GET would work as well, only adding POST, as that's the only method
that's going to be exersized in code and tests (RPC mdssvc elasticsearch
backend).
Signed-off-by: Ralph Boehme <slow@samba.org> Reviewed-by: Samuel Cabrero <scabrero@suse.de>