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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's the job of the domain controller in our domain
to traverse the trust chain.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
This test is already slow. We should not run it twice!
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Sat Mar 11 04:25:14 CET 2017 on sn-devel-144
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12554
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12554
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12554
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12554
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
I noticed smbd can get stuck in an open() call with kernel oplocks
enabled and named streams (provided by vfs_streams_xattr):
- client opens a file and with an exclusive oplock
- client starts writing to the file
- client opens an existing stream of the file
- the smbd process gets stuck in an open()
What happens is:
we had setup a locking.tdb record watch in defer_open(), the watch was
triggered, we reattempted the open and got stuck in a blocking open
because the oplock holder (ourselves) hadn't given up the oplock yet.
Cf e576bf5310bc9de9686a71539e9a1b60b4fba5cc for the commit that added
the kernel oplock retry logic. tldr: with kernel oplocks the first open
is non-blocking, but the second one is blocking.
Detailed analysis follows.
When opening a named stream of a file, Samba internally opens the
underlying "base" file first. This internal open of the basefile suceeds
and does *not* trigger an oplock break (because it is an internal open
that doesn't call open() at all) but it is added as an entry to the
locking.tdb record of the file.
Next, the stream open ends up in streams_xattr where a non-blocking
open() on the base file is called. This open fails with EWOULDBLOCK
because we have another fd with a kernel oplock on the file.
So we call defer_open() which sets up a watch on the locking.tdb record.
In the subsequent error unwinding code in open_file_ntcreate() and
callers we close the internal open file handle of the basefile which
also removes the entry from the locking.tdb record and so *changes the
record*.
This fires the record watch and in the callback defer_open_done() we
don't check whether the condition (oplock gone) we're interested in is
actually met. The callback blindly reschedules the open request with
schedule_deferred_open_message_smb().
schedule_deferred_open_message_smb() schedules an immediate tevent event
which has precedence over the IPC fd events in messaging, so the open is
always (!) reattempted before processing the oplock break message.
As explained above, this second open will be a blocking one so we get
stuck in a blocking open.
It doesn't help to make all opens non-blocking, that would just result
in a busy loop failing the open, as we never process the oplock break
message (remember, schedule_deferred_open_message_smb() used immediate
tevent events).
To fix this we must add some logic to the record watch callback to check
whether the record watch was done for a kernel oplock file and if yes,
check if the oplock state changed. If not, simply reschedule the
deferred open and keep waiting.
This logic is only needed for kernel oplocks, not for Samba-level
oplocks, because there's no risk of deadlocking, the worst that can
happen is a rescheduled open that fails again in the oplock checks and
gets deferred again.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
No change in behaviour. Update the function comment explaining how it
works and relies on lck for a record watch.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
schedule_async_open() was calling defer_open with sharemode lock = NULL,
as a result there was never an active 20 s timeout.
This has been broken since the commits in
$ git log --reverse -p -10 8283fd0e0090ed12b0b12d5acb550642d621b026
Just roll our own deferred record instead of calling defer_open() and
also set up timer that, as a last resort, catches stuck opens and just
exits for now.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Add a new function that does an immediate open rescheduling.
The first deferred open this commit changes was never scheduled, as the
scheduling relies on a timeout of the watch on the sharemode lock.
This has been broken since the commits in
$ git log --reverse -p -10 8283fd0e0090ed12b0b12d5acb550642d621b026
That patchset added the dbwrap watch record logic to defer_open() and
removed the timers.
I'm doing this mainly to untangle the defer_open() logic which is
complicated by the lck arg.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Add a helper function deferred_open_record_create() that creates a
deferred_open_record and let all callers pass all needed arguments
individually.
While we're at it, enhance the debug message in defer_open() to print
all variables.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
req can't be NULL because the if condition surrounding this code checks
!(oplock_request & INTERNAL_OPEN_ONLY).
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Fix a copy/paste error, the Linux kernel oplocks check was copied from
the change notify support check.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=7537
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Uri Simchoni <uri@samba.org>
Autobuild-User(master): Uri Simchoni <uri@samba.org>
Autobuild-Date(master): Fri Mar 10 00:00:15 CET 2017 on sn-devel-144
No intended code change, just reformatting and a goto fail with
inverted logic
Best viewed with "git show -b"
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 Mar 9 02:01:35 CET 2017 on sn-devel-144
No intended code change, just reformatting and a goto fail with
inverted logic
Best viewed with "git show -b" :-)
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Instead of directly assigning (*pserver_info), work on a local copy
first and assign it once when successful
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Use talloc_stackframe and talloc_tos. Don't bother to talloc_free
within the loop, we don't have many iterations.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Preparation for simplified talloc handling. Slight behaviour change:
We now ZERO_STRUCTP(pserver_info) in all failure cases.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
MIT krb5 1.9 version of gss_krb5_import_cred() may fail when importing
credentials from a keytab without specifying actual principal.
This was fixed in MIT krb5 1.9.2 (see commit
71c3be093db577aa52f6b9a9a3a9f442ca0d8f20 in MIT krb5-1.9 branch, git
master's version is bd18687a705a8a6cdcb7c140764d1a7c6a3381b5).
Move fallback code to the smb_gss_krb5_import_cred wrapper. We only
expect this fallback to happen with krb5 GSSAPI mechanism, thus hard
code use of krb5 mech when calling to gss_acquire_cred.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12611
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Alexander Bokovoy <ab@samba.org>
Autobuild-Date(master): Wed Mar 8 22:00:24 CET 2017 on sn-devel-144
ldap_search_ext_s manpage states:
Note that res parameter of ldap_search_ext_s should be freed with
ldap_msgfree() regardless of return value of these functions.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Mar 8 14:59:35 CET 2017 on sn-devel-144
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12613
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Mar 8 04:06:59 CET 2017 on sn-devel-144
Returning an error at this level gives a RPC level error without the chance to
provide !authoritative flag to the caller. At the RPC level we're fine, but not
finding the domain to authenticate means that we don't know the domain and thus
have to return !authoritative.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Tue Mar 7 13:16:00 CET 2017 on sn-devel-144
We'll need to pass "authoritative" back to the winbind client
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
In particular "authoritative" is useful at the top level
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The two callers of rpccli_netlogon_network_logon have flags set !=NULL
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The two callers of rpccli_netlogon_network_logon have authoritative
set !=NULL
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12612
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Mon Mar 6 19:18:31 CET 2017 on sn-devel-144
That simplifies the potential caller.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12612
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
