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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The HAVE_* is normally used for config.h definitions, so rename it to
USE_ASM_BYTEORDER.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
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): Wed Nov 28 21:15:31 CET 2018 on sn-devel-144
ccc was already allocated off cred, this talloc_steal was a no-op.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is an extension of bb2f7e3aee: Without this fix in the
"empty ccache" case we never set cred->ccache, so the whole call to
cli_credentials_set_ccache became pointless
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Nov 28 15:57:43 CET 2018 on sn-devel-144
drd reports:
initialized twice: cond 0x514f188
at 0x4C3A399: pthread_cond_init_intercept (drd_pthread_intercepts.c:1022)
by 0x4C3A399: pthread_cond_init@* (drd_pthread_intercepts.c:1030)
by 0x50F3FF3: tfork_atfork_child (tfork.c:250)
by 0x9A4B95D: fork (fork.c:204)
by 0x50F4834: tfork_start_waiter_and_worker (tfork.c:581)
by 0x50F4CDB: tfork_create (tfork.c:780)
by 0x2F7469: tfork_thread (tfork.c:431)
by 0x4C358F8: vgDrd_thread_wrapper (drd_pthread_intercepts.c:444)
by 0x8D46593: start_thread (pthread_create.c:463)
by 0x9A7EE6E: clone (clone.S:95)
cond 0x514f188 was first observed at:
at 0x4C3A399: pthread_cond_init_intercept (drd_pthread_intercepts.c:1022)
by 0x4C3A399: pthread_cond_init@* (drd_pthread_intercepts.c:1030)
by 0x50F413A: tfork_global_initialize (tfork.c:287)
by 0x8D4DEA6: __pthread_once_slow (pthread_once.c:116)
by 0x4C377FD: pthread_once_intercept (drd_pthread_intercepts.c:800)
by 0x4C377FD: pthread_once (drd_pthread_intercepts.c:806)
by 0x50F4C0E: tfork_create (tfork.c:743)
by 0x2F7469: tfork_thread (tfork.c:431)
by 0x4C358F8: vgDrd_thread_wrapper (drd_pthread_intercepts.c:444)
by 0x8D46593: start_thread (pthread_create.c:463)
by 0x9A7EE6E: clone (clone.S:95)
This is intentional, the reinit is in a child process. Cf the comment in
tfork.c.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
tfork_atexit_unknown[1|2]:
No idea what triggers this, definitely not tfork itself.
tfork_pthread_get_specific:
Helgrind reports:
Possible data race during read of size 4 at 0x5141304 by thread #3
Locks held: none
at 0x50E602E: tfork_global_get (tfork.c:301)
by 0x50E69B1: tfork_create (tfork.c:737)
by 0x2F7419: tfork_thread (tfork.c:431)
by 0x4C35AC5: mythread_wrapper (hg_intercepts.c:389)
by 0x8D38593: start_thread (pthread_create.c:463)
by 0x9A70E6E: clone (clone.S:95)
This conflicts with a previous write of size 4 by thread #2
Locks held: none
at 0x8D3F7B7: pthread_key_create (pthread_key_create.c:41)
by 0x50E5F79: tfork_global_initialize (tfork.c:280)
by 0x8D3FEA6: __pthread_once_slow (pthread_once.c:116)
by 0x50E6999: tfork_create (tfork.c:728)
by 0x2F7419: tfork_thread (tfork.c:431)
by 0x4C35AC5: mythread_wrapper (hg_intercepts.c:389)
by 0x8D38593: start_thread (pthread_create.c:463)
by 0x9A70E6E: clone (clone.S:95)
Location 0x5141304 is 0 bytes inside global var "tfork_global_key"
declared at tfork.c:122
This is nonsense, tfork_global_get() calls pthread_getspecific, so
we're looking at the pthread_key_create()/pthread_[g|s]etspecific()
API here which works with threads by design.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Clearly the lockOutObservationWindow value is important, and using a
default value of zero doesn't work very well.
This patch adds a better default value (the domain default setting of 30
minutes).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13683
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Karolin Seeger <kseeger@samba.org>
Autobuild-Date(master): Wed Nov 28 11:31:14 CET 2018 on sn-devel-144
Fix a remaining place where we were trying to read the
msDS-LockoutObservationWindow as an int instead of an int64.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13683
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Commit 442a38c918 refactored some code into a new
get_lockout_observation_window() function. However, in moving the code,
an ldb_msg_find_attr_as_int64() inadvertently got converted to a
ldb_msg_find_attr_as_int().
ldb_msg_find_attr_as_int() will only work for values up to -2147483648
(about 3.5 minutes in MS timestamp form). Unfortunately, the automated
tests used a low enough timeout that they still worked, however,
password lockout would not work with the Samba default settings.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13683
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Sanity-check that when we use the default lockOutObservationWindow that
user lockout actually works.
The easiest way to do this is to reuse the _test_login_lockout()
test-case, but stop at the point where we wait for the lockout duration
to expire (because we don't want the test to wait 30 mins).
This highlights a problem currently where the default values don't work.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13683
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
When calling encode_krb5_padata_sequence() make sure to
pass a null terminated array as required.
Fixes expired passowrd case in samba4.blackbox.kinit test.
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This can be triggered with FAST but we don't support this yet.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13571
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13571
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This happens when we are called from S4U2Self flow, and in that case
kdcreq->client is NULL. Use the name from client entry instead.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13571
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
By fixing bindir variable name.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13571
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
dnsserver_common.c and dnsutils.c both share similar code to process
zone properties. This patch extracts the common code and moves it to
dnsserver_common.c.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13669
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Fixes for
Bug 13669 - (CVE-2018-16852) NULL
pointer de-reference in Samba AD DC DNS management
The presence of the ZONE_MASTER_SERVERS property or the
ZONE_SCAVENGING_SERVERS property in a zone record causes the server to
follow a null pointer and terminate.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13669
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Tests to verify
Bug 13669 - (CVE-2018-16852) NULL
pointer de-reference in Samba AD DC DNS management
The presence of the ZONE_MASTER_SERVERS property or the
ZONE_SCAVENGING_SERVERS property in a zone record causes the server to
follow a null pointer and terminate.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13669
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
In the case of hitting the talloc ~256MB limit, this causes a crash in
the server.
Note that you would actually need to load >256MB of data into the LDAP.
Although there is some generated/hidden data which would help you reach that
limit (descriptors and RMD blobs).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13674
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
