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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Using a SPN should only be permitted if it is also a UPN, and is not an
enterprise principal.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is currently not checked in several places due to STRICT_CHECKING
being set to 0.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This allows us to ensure that the correct name makes it through to the
PAC.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This decreases the time that the tests take to run.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
As pointed out in https://lwn.net/Articles/875964, forbidding bidi
marker characters is not always going to be enough to avoid
right-to-left vs left-to-right confusion. Consider this:
$ python -c's = "b = x # 2 * n * m"; print(s); print(s.replace("x", "א").replace("n", "ח"))'
b = x # 2 * n * m
b = א # 2 * ח * m
Those two lines are semantically the same, with the Hebrew letters
"א" and "ח" replacing "x" and "n". But they look like they mean
different things.
It is not enough to say we only allow these scripts (or indeed
non-ascii) in strings and comments, as demonstrated in this example:
$ python -c's = "b = \"x#\" # n"; print(s); print(s.replace("x", "א").replace("n", "ח"))'
b = "x#" # n
b = "א#" # ח
where the second line is visually disordered but looks valid. Any series
of neutral characters between teo RTL characters will be reversed (and
possibly mirrored).
In practice this affects one file, which is a text file for testing
unicode normalisation.
I think, for the reasons shown above, we are unlikely to see legitimate
RTL code outside perhaps of documentation files — but if we do, we can
add those files to the allow-list.
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 Dec 3 18:53:43 UTC 2021 on sn-devel-184
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
We set EXPECT_EXTRA_PAC_BUFFERS to 0 for the moment. This signifies that
these checks are currently not enforced, which avoids a lot of test
failures.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The value of expect_pac is not considered if we are expecting an error.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We were instead always running against the DC.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
salt_tests was running the tests defined in the base class as well as
its own tests.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Mon Nov 22 11:18:09 UTC 2021 on sn-devel-184
also, we fixed the name ("arbitrary", not "arbitary").
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Nov 17 05:27:39 UTC 2021 on sn-devel-184
Unicode has format control characters that affect the appearance —
including the apparent order — of other characters. Some of these,
like the bidi controls (for mixing left-to-right scripts with
right-to-left scripts) can be used make text that means one thing look
very much like it means another thing.
The potential for duplicity using these characters has recently been
publicised under the name “Trojan Source”, and CVE-2021-42694. A
specific example, as it affects the Rust language is CVE-2021-42574.
We don't have many format control characters in our code — in fact,
just the non-breaking space (\u200b) and the redundant BOM thing
(\ufeff), and this test aims to ensure we keep it that way.
The test uses a series of allow-lists and deny-lists to check most
text files for unknown format control characters. The filtering is
fairly conservative but not exhaustive. For example, XML and text
files are checked, but UTF-16 files are not.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Ralph Boehme <slow@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14901
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
[metze@samba.org removed unused tests for a feature that
was removed before merging]
Reviewed-by: Ralph Boehme <slow@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14901
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
