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 req_state parameter tells the caller whether the async request is
blocked in a full send queue:
req_state >= DBWRAP_REQ_DISPATCHED := request is dispatched
req_state < DBWRAP_REQ_DISPATCHED := send queue is full
This is useful in a clustered Samba environment where the async dbwrap
request is sent over a socket to the local ctdbd.
If the send queue is full and the caller was issuing multiple async
dbwrap requests in a loop, the caller knows it's probably time to stop
sending requests for now and try again later.
This will be used in subsequent commits in
smbd_smb2_query_directory_send() when implementing async write time
updates. Directories may contain umpteen files so we send many requests
to ctdb without going through tevent and reading the responses which has
the potential to deadlock.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This will be used by async dwrap_parse_send() as an out argument, giving
the caller an indication about the state of the request.
This is can be useful for the caller if it is a sync function and sends
multiple async dbwrap requests. As it's a sync function it won't return
to the main tevent event loop and so the async dbwrap recv function are
not called.
As a result the function may deadlock: our receive queue may already be
full with results from a peer, the peer might be blocked in his send
queue (because we're not receiving), the peer therefor doesn't read from
his receive queue so our send queue will block as well.
To inform the caller of this situation "send queue full" we return this
state information to the caller of the dbwrap send function.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Completely unused functionality. Gets rid of another
talloc_autofree_context(). Updated WHATSNEW to make
this clear.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Report and patch from Hanno Böck <hanno@hboeck.de>.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12746
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Andreas Schneider <asn@samba.org>
All other callers use NULL here anyway, so there's no
need to use a special context for get_iconv_handle().
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Add an error check.
This *looks* like a logic change, but it is not.
The only change is the addition of the error return check.
The reason is that the changed function, reload_charcnv(),
is the *only* function that sets lp_ctx->iconv_handle. And
it does so just before setting global_iconv_handle = lp_ctx->iconv_handle.
Calling the utility function reinit_iconv_handle()
instead merely sets global_iconv_handle first, then
assigns it (as the return) to lp_ctx->iconv_handle.
So all this is doing is reversing the order of
setting global_iconv_handle and lp_ctx->iconv_handle
to the same thing.
Even the removal of the lines:
- struct smb_iconv_handle *old_ic = lp_ctx->iconv_handle
- if (old_ic == NULL) {
- old_ic = global_iconv_handle;
has no effect, as remember that lp_ctx->iconv_handle
is only ever set to the same value as global_iconv_handle,
and once this function has been run once, lp_ctx->iconv_handle != NULL.
This allows us finally to make global_iconv_handle private
to the C source file that defines it.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Not yet used. Will enable us to make global_iconv_handle private.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
It's merely a wrapper for smb_iconv_handle_reinit(),
only used in one place and smb_iconv_handle_reinit()
is already called from lib/param/loadparm.c.
Removing this will make it easier to make global_iconv_handle
private state to lib/util/charset/codepoints.c later.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
This variable is populated by a list of values where each value should
be a known option. This patch ensures that illegal values are detected.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12739
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
When a process holds a readlock and wants to upgrade, this needs to be
reflected in the underlying lock. Without this, it is possible to cheat:
One process holds a readlock, and another process wants to write this
record. All the writer has to do is take a readonly lock on the key and
then do the store.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
conf.blddir might not the the same as conf.srcdir + '/bin'.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
conf.blddir might not the the same as conf.srcdir + '/bin'.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
conf.blddir might not the the same as conf.srcdir + '/bin'.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
This will be an audit stream of authentication and connection-level authorization
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Pair-Programmed-by: Gary Lockyer <gary@catalyst.net.nz>
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
We do not want to turn every non-ascii username into a pile of hex, so we instead focus
on avoding newline insertion attacks and other low control chars
Pair-programmed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Remove the failing test from knownfail.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12705
Document change and modify in loadparm.c.
Safer default for new installs and vendors.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
We have the recalculation logic also in sys_poll_intr, don't duplicate it.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Mon Mar 20 16:11:16 CET 2017 on sn-devel-144
Implement a small Python module that exposes arcfour_crypt_blob()
function widely used in Samba C code.
When Samba Python bindings are used to call LSA CreateTrustedDomainEx2,
there is a need to encrypt trusted credentials with RC4 cipher.
Current Samba Python code relies on Python runtime to provide RC4
cipher. However, in FIPS 140-2 mode system crypto libraries do not
provide access RC4 cipher at all. According to Microsoft dochelp team,
Windows is treating AuthenticationInformation blob encryption as 'plain
text' in terms of FIPS 140-2, thus doing application-level encryption.
Replace samba.arcfour_encrypt() implementation with a call to
samba.crypto.arcfour_crypt_blob().
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Simo Sorce <idra@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
Autobuild-User(master): Günther Deschner <gd@samba.org>
Autobuild-Date(master): Wed Mar 15 01:30:24 CET 2017 on sn-devel-144
This does not build on Fedora 25 with picky-developer turned on.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
We support --option for our tools but you cannot set an option where the
value of the option includes a space.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlet <abartlet@samba.org>
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Pair-programmed-with: Andrew Bartlett <abartlet@samba.org>
This is not the time to be pretending to be dbcheck, and there are
exceptions to the single-value rules in Samba. This is needed for
the same reasons as the modify case.
(Note: this error was triggered with the demote of an RODC with links)
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Pair-programmed-with: Andrew Bartlett <abartlet@samba.org>
This behaviour of ignoring duplicates with the flag
LDB_FLAG_INTERNAL_DISABLE_SINGLE_VALUE_CHECK is also used in the replace
case here.
When we add a forward DN+Binary link with a duplicate DN, this prevents
us from not being able to add the backlink because it appears to be a
duplicate here.
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Pair-programmed-with: Bob Campbell <bobcampbell@catalyst.net.nz>
When copying large files from the server to the client with aio enabled
we noticed that smbd kept growing RSS and VSZ.
valgrind was reporting:
==2503== 4,093,440 bytes in 6,560 blocks are possibly lost in loss record 460 of 460
==2503== at 0x4C299CE: calloc (vg_replace_malloc.c:711)
==2503== by 0x4011C24: _dl_allocate_tls (in /usr/lib64/ld-2.17.so)
==2503== by 0x4E3C960: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.17.so)
==2503== by 0x9B298AE: pthreadpool_add_job (in /usr/lib64/samba/libmessages-dgm-samba4.so)
==2503== by 0x9B29FDC: pthreadpool_tevent_job_send (in /usr/lib64/samba/libmessages-dgm-samba4.so)
==2503== by 0x56A78EF: ??? (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x55D86B7: smb_vfs_call_pread_send (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x55F7543: schedule_smb2_aio_read (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x5608F57: smbd_smb2_request_process_read (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x55FCB6C: smbd_smb2_request_dispatch (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x55FD7DC: ??? (in /usr/lib64/samba/libsmbd-base-samba4.so)
==2503== by 0x641B977: ??? (in /usr/lib64/samba/libtevent.so.0.9.31)
The problem seems to be caused by worked threads that are not properly
started in detached state and thus their tls is not reclaimed upon
thread termination.
In pthreadpool.c we prepare a pthread attribute with
PTHREAD_CREATE_DETACHED, but we don't pass it to pthread_create().
Bug: https://bugzilla.samba.org/show_bug.cgi?id=12624
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Fri Mar 10 22:06:02 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>
