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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Pass a pointer to the struct instead of all struct members individually. No
change in behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Pass a pointer to the struct instead of all struct members individually. No
change in behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Take an incoming const char * pointer and return an allocated
array that must be freed. Don't expose the internal optimization
of file_lines_parse_internal() breaking the passed in string
into lines.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
Make the internal function file_lines_parse_internal().
Currently file_lines_parse() just wraps file_lines_parse_internal(),
but this allows me to change file_lines_parse() to take
a const char * to make it safe for callers (no talloc tricks).
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
Make clear that generate_unique_u64() is the only function referencing
it.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is now never set, and also never tested, and only makes
the talloc code more complicated.
Once this is gone we can start looking at the memlimit
stuff.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Solaris Studio compiler 12.4 is pedantic about prototypes in headers having
the external visibility declarations too. It throws errors like:
redeclaration must have the same or more restrictive linker scoping: ...
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Solaris Studio compiler 12.4 is pedantic about prototypes in headers having
the external visibility declarations too. It throws errors like:
redeclaration must have the same or more restrictive linker scoping: ...
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Solaris Studio compiler 12.4 is pedantic about prototypes in headers having
the external visibility declarations too. It throws errors like:
redeclaration must have the same or more restrictive linker scoping: ...
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This requires the previous patch.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We only have to do the memlimit check before any
real malloc or realloc. Allocations out of a
memory pool have already been counted in the
memory limit, so don't check in those cases.
This is an application-visible change (although
fixing a bug) so bump the ABI to 2.3.1 -> 2.3.2.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
tc_alloc_pool() or the fallback malloc can return NULL.
Wait until we know we are returning a valid pointer
before decrementing pool_hdr->object_count due to
reallocing out of the talloc_pool.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Douglas Bagnall <dbagnall@samba.org>
Autobuild-Date(master): Fri Oct 23 00:33:57 UTC 2020 on sn-devel-184
It is much harder to determine why we get messages like
Step #6: Error occured while running fuzz_reg_parse:
Step #6: /workspace/out/coverage/fuzz_reg_parse: error while loading shared libraries: libavahi-common.so.3: cannot open shared object file: No such file or directory
instead this detects the failure to use RPATH (which is
strictly required instead of the modern RUNPATH)
otherwise.
We do this by creating a new build_samba.sh after renaming
build_samba.sh to do_build.sh because this is what oss-fuzz
runs, meaning we don't need to coordinate a MR there as well.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
We strictly require RPATH, so fix the comment to avoid mentioning
the modern RUNPATH which is almost but not entirely similar.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This includes a revert of commit e60df21499.
We strictly require RPATH, not the modern RUNPATH for the behaviour
we need in oss-fuzz, which is that not just the first line of dependencies
but the full set of libraries used by the program are looked for in the
'$ORIGIN/lib' directory.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Douglas Bagnall <dbagnall@samba.org>
Autobuild-Date(master): Thu Oct 22 14:10:04 UTC 2020 on sn-devel-184
This tries to make progress towards understanding why we sometime see errors like
Step #6: Error occured while running fuzz_reg_parse:
Step #6: /workspace/out/coverage/fuzz_reg_parse: error while loading shared libraries: libavahi-common.so.3: cannot open shared object file: No such file or directory
in the previously failing coverage builds.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This function calls talloc_strdup() for the parm_name passed into
it so that we can check whether it's a parametric entry. It's
allocated under the loadparm context passed into the function.
Primary consumer of this is "testparm" and so context short-lived in
typical use-case, but this is also exposed via pyparam and so the
loadparm context may be somewhat longer-lived depending on how it is
being used.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14544
Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
It was long thought that the issue here was that no seed corpus was
provided, but actually the issue is that to obtain coverage output
just as we already know for gcc gcov, you must provide fuzzing flags
to both the compile and link phase.
Thankfully clang as a linker does not mind the strange non-linker options
from $COVERAGE_FLAGS.
REF: https://stackoverflow.com/questions/56112019/clang-does-not-generate-profraw-file-when-linking-manually
REF: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19495#c48
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Oct 21 23:07:37 UTC 2020 on sn-devel-184
There is a git repository at
https://gitlab.com/samba-team/samba-fuzz-seeds that contains the
seeds. When the master branch of that repository is updated, a CI job
runs that creates a zip file of all the seeds as an artifact. That zip
file is downloaded and unpacked by oss_fuzz/build_samba. The contents
of that zip are further zips that contain the seeds for each fuzzing
binary; these are placed next to the binaries in the manner that
oss-fuzz expects.
That is, beside 'fuzz_foo', we put 'fuzz_foo_seed_corpus.zip' which
contains a pile of fuzz_foo seeds.
There may be times when a new fuzz target does not have a seed corpus,
and times when a removed fuzz target leaves behind a seed corpus.
This is OK, so we don't insist on an exact match between the target
names and the zip names, only that there is some overlap.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Oct 21 03:47:35 UTC 2020 on sn-devel-184
Also, by not tallocing at all in the too-long case, we can short
circuit quicker.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Oct 20 02:26:40 UTC 2020 on sn-devel-184
We parse a binding and do a few tricks with it, including turning it
into a tower and back.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Move of strcasecmp redefine to lib/util/safe_string.h in
https://gitlab.com/samba-team/samba/-/merge_requests/1507 broke build on
Fedora 33 with GCC 10.2.1 for those compilation units that use
ldb_att_cmp().
The reason for that is that ldb_attr_cmp() defined as
#define ldb_attr_cmp(a, b) strcasecmp(a, b)
because attribute names restricted to be ASCII by RFC2251 (LDAPv3 spec).
A solution is to add
#undef strcasecmp
to all source code files which use ldb_attr_cmp().
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Oct 1 22:45:29 UTC 2020 on sn-devel-184
Otherwise GSSAPI will consult other mechanisms if available and we can
only cope with krb5 credentials here.
Signed-off-by: Simo Sorce <idra@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Sep 30 20:45:23 UTC 2020 on sn-devel-184
Why? This simplifies the code.
Why do I believe we can do this? I don't think this is a very common
operation in critical code paths. Also, next_codepoint() already has
the same optimization. If this turns out to be a measurable
performance issue, we should turn next_codepoint() into a static
inline function doing the 7-bit optimized code path inlined the same
way we did it for tdb_oob(). This way all callers would benefit from
this optimization.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
UBSAN does not like an int >= 1<<24 being shifted left.
We check the overflow in the very next line.
Credit to OSS-Fuzz.
REF: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25436
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Sep 11 05:05:59 UTC 2020 on sn-devel-184
