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 2007, we've added support for multiple lookup levels for LSA
LookupNames family of calls. However, forest-wide lookups, as described
in MS-LSAT 2.2.16, never worked because flags passed to lookup_name()
were always set to zero, expecting at least default lookup on a DC to
apply. lookup_name() was instead treating zero flags as 'skip all
checks'.
Allow at least own domain lookup in case domain name is the same.
This should allow FreeIPA DC to respond to LSA LookupNames3 calls from a
trusted AD DC side.
For the reference, below is a request Windows Server 2016 domain
controller sends to FreeIPA domain controller when attempting to look up
a user from a trusted forest root domain that attemps to login to the
domain controller. Notice the level in the lsa_LookupNames3 call and
resulting flags in lookup_name().
[2019/08/03 07:14:24.156065, 1, pid=23639, effective(967001000, 967001000), real(967001000, 0), class=rpc_parse] ../../librpc/ndr/ndr.c:471(ndr_print_function_debug)
lsa_LookupNames3: struct lsa_LookupNames3
in: struct lsa_LookupNames3
handle : *
handle: struct policy_handle
handle_type : 0x00000000 (0)
uuid : 0000004c-0000-0000-455d-3018575c0000
num_names : 0x00000001 (1)
names: ARRAY(1)
names: struct lsa_String
length : 0x000a (10)
size : 0x000c (12)
string : *
string : 'XS\ab'
sids : *
sids: struct lsa_TransSidArray3
count : 0x00000000 (0)
sids : NULL
level : LSA_LOOKUP_NAMES_UPLEVEL_TRUSTS_ONLY2 (6)
count : *
count : 0x00000000 (0)
lookup_options : LSA_LOOKUP_OPTION_SEARCH_ISOLATED_NAMES (0)
client_revision : LSA_CLIENT_REVISION_2 (2)
[2019/08/03 07:14:24.156189, 6, pid=23639, effective(967001000, 967001000), real(967001000, 0), class=rpc_srv] ../../source3/rpc_server/rpc_handles.c:339(find_policy_by_hnd_internal)
Found policy hnd[0] [0000] 00 00 00 00 4C 00 00 00 00 00 00 00 45 5D 30 18 ....L... ....E]0.
[0010] 57 5C 00 00 W\..
[2019/08/03 07:14:24.156228, 4, pid=23639, effective(967001000, 967001000), real(967001000, 0)] ../../source3/smbd/sec_ctx.c:215(push_sec_ctx)
push_sec_ctx(967001000, 967001000) : sec_ctx_stack_ndx = 2
[2019/08/03 07:14:24.156246, 4, pid=23639, effective(967001000, 967001000), real(967001000, 0)] ../../source3/smbd/uid.c:552(push_conn_ctx)
push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2019/08/03 07:14:24.156259, 4, pid=23639, effective(967001000, 967001000), real(967001000, 0)] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 2
[2019/08/03 07:14:24.156273, 5, pid=23639, effective(967001000, 967001000), real(967001000, 0)] ../../libcli/security/security_token.c:53(security_token_debug)
Security token: (NULL)
[2019/08/03 07:14:24.156285, 5, pid=23639, effective(967001000, 967001000), real(967001000, 0)] ../../source3/auth/token_util.c:865(debug_unix_user_token)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2019/08/03 07:14:24.156311, 5, pid=23639, effective(0, 0), real(0, 0), class=rpc_srv] ../../source3/rpc_server/lsa/srv_lsa_nt.c:244(lookup_lsa_sids)
lookup_lsa_sids: looking up name XS\ab
[2019/08/03 07:14:24.156327, 10, pid=23639, effective(0, 0), real(0, 0)] ../../source3/passdb/lookup_sid.c:112(lookup_name)
lookup_name: XS\ab => domain=[XS], name=[ab]
[2019/08/03 07:14:24.156340, 10, pid=23639, effective(0, 0), real(0, 0)] ../../source3/passdb/lookup_sid.c:114(lookup_name)
lookup_name: flags = 0x00
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
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): Wed Aug 14 11:48:42 UTC 2019 on sn-devel-184
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 13 00:42:09 UTC 2019 on sn-devel-184
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): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Mon Aug 12 01:18:45 UTC 2019 on sn-devel-184
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>
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>
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>
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>
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>
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>
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>
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>
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>
==24948==ERROR: LeakSanitizer: detected memory leaks
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
* Assign *file_created on every exit.
* Directly assign curr_flags without &= / |=
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
Taken from macOS. We have to return an empty share_path and an empty policy
handle, but not fail the RPC request.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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>
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:
$ bin/rpcclient -U slow%pass macmini -c "fetch_attributes xxx /foo/bar 123" -d 10
....
Got pdu len 56, data_len 32
rpc_api_pipe: got frag len of 56 at offset 0: NT_STATUS_OK
rpc_api_pipe: host macmini returned 32 bytes.
mdssvc_cmd: struct mdssvc_cmd
out: struct mdssvc_cmd
fragment : *
fragment : 0x00000000 (0)
response_blob : *
response_blob: struct mdssvc_blob
length : 0x00000000 (0)
size : 0x00010000 (65536)
spotlight_blob : *
spotlight_blob: ARRAY(0)
unkn9 : *
unkn9 : 0x00000000 (0)
...
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
