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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This allows us to make use of it in other tests.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15047
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
The environment variable is a string, but we expect an integer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15074
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
The target principal and realm fields of the setpw structure are
supposed to be optional, but in MIT Kerberos they are mandatory. For
better compatibility and ease of testing, fall back to parsing the
simpler (containing only the new password) structure if the MIT function
fails to decode it.
Although the target principal and realm fields should be optional, one
is not supposed to specified without the other, so we don't have to deal
with the case where only one is specified.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15047
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15049
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15074
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
So that we do not confuse TGTs and kpasswd tickets, it is critical to
check that the REQUESTER_SID buffer exists in TGTs, and to ensure that
it is not propagated to service tickets.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15047
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
It's not necessary to repeat the required environment variables for
every test.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit e729606631)
To use memcpy(), we need to specify the number of bytes to copy, rather
than the number of ldb_val structures.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Currently, we can crash the server by sending a large number of values
of a specific attribute (such as sAMAccountName) spread across a few
message elements. If val_count is larger than the total number of
elements, we get an access beyond the elements array.
Similarly, we can include unrelated message elements prior to the
message elements of the attribute in question, so that not all of the
attribute's values are copied into the returned elements values array.
This can cause the server to access uninitialised data, likely resulting
in a crash or unexpected behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
This aims to minimise usage of the error-prone pattern of searching for
a just-added message element in order to make modifications to it (and
potentially finding the wrong element).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Currently, there are many places where we use ldb_msg_add_empty() to add
an empty element to a message, and then call ldb_msg_add_value() or
similar to add values to that element. However, this performs an
unnecessary search of the message's elements to locate the new element.
Moreover, if an element with the same attribute name already exists
earlier in the message, the values will be added to that element,
instead of to the intended newly added element.
A similar pattern exists where we add values to a message, and then call
ldb_msg_find_element() to locate that message element and sets its flags
to (e.g.) LDB_FLAG_MOD_REPLACE. This also performs an unnecessary
search, and may locate the wrong message element for setting the flags.
To avoid these problems, add functions for appending a value to a
message, so that a particular value can be added to the end of a message
in a single operation.
For ADD requests, it is important that no two message elements share the
same attribute name, otherwise things will break. (Normally,
ldb_msg_normalize() is called before processing the request to help
ensure this.) Thus, we must be careful not to append an attribute to an
ADD message, unless we are sure (e.g. through ldb_msg_find_element())
that an existing element for that attribute is not present.
These functions will be used in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Using the newly added ldb flag, we can now detect when a message has
been shallow-copied so that its elements share their values with the
original message elements. Then when adding values to the copied
message, we now make a copy of the shared values array first.
This should prevent a use-after-free that occurred in LDB modules when
new values were added to a shallow copy of a message by calling
talloc_realloc() on the original values array, invalidating the 'values'
pointer in the original message element. The original values pointer can
later be used in the database audit logging module which logs database
requests, and potentially cause a crash.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
When making a shallow copy of an ldb message, mark the message elements
of the copy as sharing their values with the message elements in the
original message.
This flag value will be heeded in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to
(el->flags & LDB_FLAG_MOD_MASK) == 0
which is only true if none of the LDB_FLAG_MOD_* values are set, so we
would not successfully return if the element was a DELETE. Correct the
expression to what it was intended to be.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to
(el->flags & LDB_FLAG_MOD_MASK) == 0
which is only true if none of the LDB_FLAG_MOD_* values are set. Correct
the expression to what it was probably intended to be.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to
(req_msg->elements[el_idx].flags & LDB_FLAG_MOD_MASK) != 0
which is true whenever any of the LDB_FLAG_MOD_* values are set. Correct
the expression to what it was probably intended to be.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
If an account has an SPN that requires Write Property to set, we should
still be able to delete it with just Validated Write.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
The function can build the service principal itself, there is no
need to do it in the caller. This removes code duplication.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14979
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 8bef8e3de9)
Split lib/krb5/crypto to its own subsystem to built with its own CFLAGS
and avoid the following error:
[1510/4771] Compiling third_party/heimdal/lib/krb5/crypto.c
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘_krb5_internal_hmac’:
../../third_party/heimdal/lib/krb5/crypto.c:302:24: warning: cast discards ‘const’ qualifier from pointer target type [-Wcast-qual]
302 | iov[0].data.data = (void *) data;
| ^
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘derive_key_sp800_hmac’:
../../third_party/heimdal/lib/krb5/crypto.c:2427:18: warning: cast discards ‘const’ qualifier from pointer target type [-Wcast-qual]
2427 | label.data = (void *)constant;
| ^
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘decrypt_internal_derived’:
../../third_party/heimdal/lib/krb5/crypto.c:1280:9: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free]
1280 | free(p);
| ^~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c:1278:20: note: call to ‘realloc’ here
1278 | result->data = realloc(p, l);
| ^~~~~~~~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘decrypt_internal_enc_then_cksum’:
../../third_party/heimdal/lib/krb5/crypto.c:1365:9: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free]
1365 | free(p);
| ^~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c:1363:20: note: call to ‘realloc’ here
1363 | result->data = realloc(p, l);
| ^~~~~~~~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘decrypt_internal’:
../../third_party/heimdal/lib/krb5/crypto.c:1431:9: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free]
1431 | free(p);
| ^~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c:1429:20: note: call to ‘realloc’ here
1429 | result->data = realloc(p, l);
| ^~~~~~~~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c: In function ‘decrypt_internal_special’:
../../third_party/heimdal/lib/krb5/crypto.c:1478:9: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free]
1478 | free(p);
| ^~~~~~~
../../third_party/heimdal/lib/krb5/crypto.c:1476:20: note: call to ‘realloc’ here
1476 | result->data = realloc(p, sz);
| ^~~~~~~~~~~~~~
cc1: all warnings being treated as errors
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15095
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Samuel Cabrero <scabrero@samba.org>
Autobuild-Date(master): Tue Jun 14 10:16:18 UTC 2022 on sn-devel-184
(cherry picked from commit 971441ca52)
Commit 86f7af84 introduced a problem that a chown is always attempted,
even when the owning gid did not change. Then the ACL is set in the file
system as root. Fix the check by correctly comparing with gid, not uid.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15120
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Christof Schmitt <cs@samba.org>
Autobuild-Date(master): Wed Jul 13 17:30:30 UTC 2022 on sn-devel-184
(cherry picked from commit a6ccceb97e)
If you pass in dirfsp!=conn->cwd_fsp and a stream fsp, we don't chdir
to the parent pathname, and thus we also don't overwrite
fsp->base_fsp.
fsp->base_fsp!=NULL is thus the wrong condition to restore the
original base fsp name: If we open a stream with a non-cwd_fsp dirfsp,
we would overwrite fsp->base_fsp->fsp_name with NULL.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15105
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from commit 280e9191cb)
With the new dcerpc architecture we need to keep printer-list.tdb
around. A spoolss dcerpc call will start rpc-spoolssd which will then
start the background queue process. However in order to enum the
printers we need have a printer-list.tdb. Depending on the number of
printers this task can take several seconds. It is unlinkly that
the printer-list will change all the time, so we might provide outdated
data till it gets refreshed, but this is better than providing no
printer list at all.
If there are a lot of printers, the idle_seconds for the rpc-spoolssd
should be increased so that the background task can finish.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15082
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from commit 9080cd30d5)
Error: ldconfig: /lib64/libsmbconf.so.0 is not a symbolic link
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15108
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
(cherry picked from commit 8458449ddf)
Autobuild-User(v4-16-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-16-test): Mon Jun 27 08:25:10 UTC 2022 on sn-devel-184
vfs_fruit passes a synthetic filename here where smb_fname->fsp==NULL
when configured to use "fruit:resource = stream" so we need to use
synthetic_pathref() to get an fsp on the smb_fname->base_name
in order to call SMB_VFS_FREMOVEXATTR().
This is the same change we already use in streams_xattr_renameat()
and streams_xattr_stat(), the other pathname operations we implement
here.
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15099
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Mon Jun 20 14:24:20 UTC 2022 on sn-devel-184
(backported from commit 808a7b8b76)
Autobuild-User(v4-16-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-16-test): Thu Jun 23 08:43:30 UTC 2022 on sn-devel-184
