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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I just came across this failure with a new test:
==16654== Invalid read of size 4
==16654== at 0x4950947: tevent_req_is_in_progress (tevent_req.c:270)
==16654== by 0x5AEEE8F: writev_trigger (async_sock.c:375)
==16654== by 0x494F9E7: tevent_queue_immediate_trigger (tevent_queue.c:149)
==16654== by 0x494F53C: tevent_common_invoke_immediate_handler (tevent_immediate.c:166)
==16654== by 0x494F642: tevent_common_loop_immediate (tevent_immediate.c:203)
==16654== by 0x4959E5E: epoll_event_loop_once (tevent_epoll.c:918)
==16654== by 0x495665A: std_event_loop_once (tevent_standard.c:110)
==16654== by 0x494DFCE: _tevent_loop_once (tevent.c:772)
==16654== by 0x4950A6A: tevent_req_poll (tevent_req.c:300)
==16654== by 0x4D166C9: tevent_req_poll_ntstatus (tevent_ntstatus.c:109)
==16654== by 0x18C98B: run_readdir_timestamp (test_readdir_timestamp.c:489)
==16654== by 0x161BC5: run_test (torture.c:14896)
==16654== by 0x162726: main (torture.c:15136)
==16654== Address 0x91bb878 is 216 bytes inside a block of size 853 free'd
==16654== at 0x48369AB: free (vg_replace_malloc.c:530)
==16654== by 0x49B405E: _tc_free_internal (talloc.c:1221)
==16654== by 0x49B4116: _talloc_free_internal (talloc.c:1247)
==16654== by 0x49B547C: _talloc_free (talloc.c:1789)
==16654== by 0x50ECE3B: smb2cli_req_writev_done (smbXcli_base.c:3468)
==16654== by 0x4950648: _tevent_req_notify_callback (tevent_req.c:141)
==16654== by 0x49507A9: tevent_req_finish (tevent_req.c:193)
==16654== by 0x49507D6: _tevent_req_done (tevent_req.c:199)
==16654== by 0x5AEEE28: writev_do (async_sock.c:363)
==16654== by 0x5AEEE83: writev_trigger (async_sock.c:374)
==16654== by 0x494F9E7: tevent_queue_immediate_trigger (tevent_queue.c:149)
==16654== by 0x494F53C: tevent_common_invoke_immediate_handler (tevent_immediate.c:166)
==16654== by 0x494F642: tevent_common_loop_immediate (tevent_immediate.c:203)
==16654== by 0x4959E5E: epoll_event_loop_once (tevent_epoll.c:918)
==16654== by 0x495665A: std_event_loop_once (tevent_standard.c:110)
==16654== by 0x494DFCE: _tevent_loop_once (tevent.c:772)
==16654== by 0x4950A6A: tevent_req_poll (tevent_req.c:300)
==16654== by 0x4D166C9: tevent_req_poll_ntstatus (tevent_ntstatus.c:109)
==16654== by 0x18C98B: run_readdir_timestamp (test_readdir_timestamp.c:489)
==16654== by 0x161BC5: run_test (torture.c:14896)
==16654== by 0x162726: main (torture.c:15136)
==16654== Block was alloc'd at
==16654== at 0x483577F: malloc (vg_replace_malloc.c:299)
==16654== by 0x49B300F: __talloc_with_prefix (talloc.c:782)
==16654== by 0x49B31E6: _talloc_pool (talloc.c:837)
==16654== by 0x49B3394: _talloc_pooled_object (talloc.c:905)
==16654== by 0x49501A6: _tevent_req_create (tevent_req.c:79)
==16654== by 0x5AEE956: writev_send (async_sock.c:266)
==16654== by 0x50ECBCA: smb2cli_req_compound_submit (smbXcli_base.c:3396)
==16654== by 0x50ECD49: smb2cli_req_send (smbXcli_base.c:3447)
==16654== by 0x50FE34F: smb2cli_create_send (smb2cli_create.c:153)
==16654== by 0x490325E: cli_smb2_create_fnum_send (cli_smb2_fnum.c:273)
==16654== by 0x48D0146: cli_ntcreate_send (clifile.c:2504)
==16654== by 0x18B737: create_ts_send (test_readdir_timestamp.c:59)
==16654== by 0x18BF77: create_ts_files_send (test_readdir_timestamp.c:253)
==16654== by 0x18C35C: create_files_send (test_readdir_timestamp.c:336)
==16654== by 0x18C953: run_readdir_timestamp (test_readdir_timestamp.c:482)
==16654== by 0x161BC5: run_test (torture.c:14896)
==16654== by 0x162726: main (torture.c:15136)
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 Apr 23 21:53:38 UTC 2020 on sn-devel-184
This was added by bd90ca6f00 (my bad) but it breaks filesystems with NFS4
permissions.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Apr 23 19:50:38 UTC 2020 on sn-devel-184
On debian buster, this variable doesn't exist anymore. Look at this PR
as a reference:
https://github.com/gluster/storhaug/pull/30
Signed-off-by: Renaud Fortier <renaud.fortier@fsaa.ulaval.ca>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Thu Apr 23 08:07:51 UTC 2020 on sn-devel-184
The LDAP backend for the Samba AD DC, aiming to store the AD DC in
an existing LDAP server was largely removed many years aga, but the
other parts were removed in 2b0fc74a09.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Apr 23 06:12:20 UTC 2020 on sn-devel-184
Doing directory scans on the path components is not going to change this, so
give up early. No change in behaviour, as we would just fail later in
get_real_filename() otherwise.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Apr 22 21:08:39 UTC 2020 on sn-devel-184
That code was moved into source3/lib/util_path.c.
We now have *one* canonicalize_absolute_path() funtion,
tested more completely.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Apr 22 09:51:08 UTC 2020 on sn-devel-184
All of the tests that were in there
are now tested in samba3.smbtorture_s3.LOCAL-CANONICALIZE-PATH
along with other paths.
Clean revert of f7fe347429 not possible due to
changes in source3/selftest/tests.py
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This code is *much* more comprehensible and passes the
stricter test set than the original (unfixed) canonicalize_absolute_path()
out of the gate.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
canonicalize_absolute_path() has a bug.
In canonicalize_absolute_path()
///a/./././///component/../////path/ -> /a//path
It should go to /a/path. Mark as knownfail.
Adding these tests so I can ultimately remove
resolve_realpath_name() and re-use the existing
canonicalize_absolute_path() code in vfs_widelinks.c
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We now pass smbtorture3 SMB2-SACL like Windows 10 does.
Note this is an SMB2-only behavior. SMB1 allows an open
with only SEC_FLAG_SYSTEM_SECURITY set as tested in
smbtorture3 SMB1-SYSTEM-SECURITY.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Apr 21 20:17:10 UTC 2020 on sn-devel-184
No logic change but uses modern formatting and will
make it easier to add another clause in the next commit.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
smbtorture3 SMB2-SAL test shows this is needed as we store the SACL in the same
data store as the DACL.
Without this, opening a file with SEC_FLAG_SYSTEM_SECURITY | READ_ATTRIBUTES
would do a stat open, meaning when we call SMB_VFS_FGET_NT_ACL()
on the fsp we have no open fd to work on.
Pair-Programmed-With: Jeremy Allison <jra@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
smbtorture3 SMB2-SACL tests this against Windows10 (and Samba).
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Calls the test in the previous commit by adding
SeSecurityPrivilege first, running the SMB2-SACL test
then removing SeSecurityPrivilege.
Demonstrates the difference between server behavior
with SEC_FLAG_SYSTEM_SECURITY against SMB1 and SMB2 servers.
Mark as knownfail for now.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Shows bits needed to set/get a SACL. We need a script within Samba to run this
as it depends on a user with SeSecurityPrivilege to work.
Test does the following:
1). Create a test file.
2). Open with SEC_FLAG_SYSTEM_SECURITY *only*. ACCESS_DENIED.
NB. SMB2-only behavior. SMB1 allows this as tested in SMB1-SYSTEM-SECURITY.
3). Open with SEC_FLAG_SYSTEM_SECURITY|FILE_WRITE_ATTRIBUTES.
4). Write SACL. Should fail with ACCESS_DENIED (seems to need WRITE_DAC).
5). Close (3).
6). Open with SEC_FLAG_SYSTEM_SECURITY|SEC_STD_WRITE_DAC.
7). Write SACL. Success.
8). Close (4).
9). Open with SEC_FLAG_SYSTEM_SECURITY|READ_ATTRIBUTES.
10). Read SACL. Success.
11). Read DACL. Should fail with ACCESS_DENIED (no READ_CONTROL).
12). Close (9).
13 - and on error). Delete test file.
Passes against Windows 10.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Calls the test in the previous commit by adding
SeSecurityPrivilege first, running the SMB1-SYSTEM-SECURITY
test then removing SeSecurityPrivilege.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
NB. This is also tested in samba3.base.createx_access
but this makes it very explicit what we're looking for.
Shows SMB1 allows explicit open of a file with only
he SEC_FLAG_SYSTEM_SECURITY access mask requested.
SMB2 doesn't.
Requires a Windows 10 system with a user with
SeSecurityPrivilege set. Passes against Windows 10
with SMB1 enabled.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
It's only used in net_rap.c, expansion to other users is
unlikely. Don't link it into libsmbclient anymore. It saves roughly
50k from the everywhere-linked libsmb.
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): Sat Apr 18 04:12:48 UTC 2020 on sn-devel-184
We have the domain browsing functionality in libsmbclient, don't
duplicate it in smbtree with special code. Not too much gain in lines
of code, but the new code is much more regular and reuses
functionality provided elsewhere.
This removes the "-b" option from smbtree, libsmbclient always does
that.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We need READ_CONTROL, and actually have to ask for
the OWNER|GROUP|DACL bits if we're going to properly
check the SD.
Tested against Windows 10.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Apr 16 20:42:58 UTC 2020 on sn-devel-184
The sdread test just added shows that a client
can open with READ_ATTRIBUTES and still issue
a query security descriptor. smbd passed that
test as it read the on-disk sd, but then threw
the information away and returned the NULL sd
the client expects.
Make sure that we don't try and read the on-disk
sd if the client doesn't request any bits.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
If we open a file without READ_CONTROL, requesting a security
descriptor fails with ACCESS_DENIED if any of the requested
bits OWNER|GROUP|DACL are set.
However, if we send zero as the requested bits then a
security descriptor is returned containing no data,
even though reading an SD should fail based on the
access permissions we have on the handle.
This has been tested against Windows 10, and also
passes on Samba - although in smbd we actually
read the SD off disk first, before nulling out
all the data we read. We shouldn't (we have
no rights to do so) and a subsequent commit
will fix this.
This was discovered when investigating the
smb2.winattr test, which currently relies
on exactly this behavior. It shouldn't
and the next commit will fix that.
I wanted to preserve the current smb2.winattr
behavior in a test though.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Modify the test to also set the create_time, and specify the year with
using four digits to test the new codepath.
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
We free gse_ctx->k5ctx but then free it again in the
talloc dtor. This patch just lets the talloc dtor handle
things and removes the extra krb5_free_context
Failed to resolve credential cache 'DIR:/run/user/1000/krb5cc'! (No credentials cache found)
==30762== Invalid read of size 8
==30762== at 0x108100F4: k5_os_free_context (in /usr/lib64/libkrb5.so.3.3)
==30762== by 0x107EA661: krb5_free_context (in /usr/lib64/libkrb5.so.3.3)
==30762== by 0x7945D2E: gse_context_destructor (gse.c:84)
==30762== by 0x645FB49: _tc_free_internal (talloc.c:1157)
==30762== by 0x645FEC5: _talloc_free_internal (talloc.c:1247)
==30762== by 0x646118D: _talloc_free (talloc.c:1789)
==30762== by 0x79462E4: gse_context_init (gse.c:241)
==30762== by 0x794636E: gse_init_client (gse.c:268)
==30762== by 0x7947602: gensec_gse_client_start (gse.c:786)
==30762== by 0xBC87A3A: gensec_start_mech (gensec_start.c:743)
==30762== by 0xBC87BC6: gensec_start_mech_by_ops (gensec_start.c:774)
==30762== by 0xBC8167F: gensec_spnego_client_negTokenInit_step (spnego.c:633)
==30762== Address 0x17259928 is 40 bytes inside a block of size 496 free'd
==30762== at 0x4C2F50B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30762== by 0x79462CA: gse_context_init (gse.c:238)
==30762== by 0x794636E: gse_init_client (gse.c:268)
==30762== by 0x7947602: gensec_gse_client_start (gse.c:786)
==30762== by 0xBC87A3A: gensec_start_mech (gensec_start.c:743)
==30762== by 0xBC87BC6: gensec_start_mech_by_ops (gensec_start.c:774)
==30762== by 0xBC8167F: gensec_spnego_client_negTokenInit_step (spnego.c:633)
==30762== by 0xBC813E2: gensec_spnego_client_negTokenInit_start (spnego.c:537)
==30762== by 0xBC84084: gensec_spnego_update_pre (spnego.c:1943)
==30762== by 0xBC83AE5: gensec_spnego_update_send (spnego.c:1741)
==30762== by 0xBC85622: gensec_update_send (gensec.c:449)
==30762== by 0x551BFD0: cli_session_setup_gensec_local_next (cliconnect.c:997)
==30762== Block was alloc'd at
==30762== at 0x4C306B5: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30762== by 0x107EA7AE: krb5_init_context_profile (in /usr/lib64/libkrb5.so.3.3)
==30762== by 0xB853215: smb_krb5_init_context_common (krb5_samba.c:3597)
==30762== by 0x794615B: gse_context_init (gse.c:209)
==30762== by 0x794636E: gse_init_client (gse.c:268)
==30762== by 0x7947602: gensec_gse_client_start (gse.c:786)
==30762== by 0xBC87A3A: gensec_start_mech (gensec_start.c:743)
==30762== by 0xBC87BC6: gensec_start_mech_by_ops (gensec_start.c:774)
==30762== by 0xBC8167F: gensec_spnego_client_negTokenInit_step (spnego.c:633)
==30762== by 0xBC813E2: gensec_spnego_client_negTokenInit_start (spnego.c:537)
==30762== by 0xBC84084: gensec_spnego_update_pre (spnego.c:1943)
==30762== by 0xBC83AE5: gensec_spnego_update_send (spnego.c:1741)
==30762==
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14344
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Tue Apr 14 22:55:51 UTC 2020 on sn-devel-184
Fixes the following flapping test:
UNEXPECTED(failure): samba4.libsmbclient.utimes.SMB3.utimes(nt4_dc)
REASON: Exception: Exception: ../../source4/torture/libsmbclient/libsmbclient.c:1249:
st.st_mtim.tv_nsec / 1000 was 98181 (0x17F85),
expected 1098181 (0x10C1C5): smbc_utimes did not update msec
https://gitlab.com/samba-team/devel/samba/-/jobs/506361470
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Sat Apr 11 12:24:00 UTC 2020 on sn-devel-184
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Apr 9 21:21:46 UTC 2020 on sn-devel-184
Now we removed the lp_widelinks() clause we
left an extra {..} level of indirection. Just
reformat to remove it. No logic changes.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Now we removed the lp_widelinks() clause we
left an extra {..} level of indirection. Just
reformat to remove it and update to modern
DBG_ macros. No logic changes
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Share path definitions don't need to be aware of symlinks.
This is strictly a change in behavior, but the vfs_widelinks
module (if loaded) copes with symlinks in the share definition.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Share path definitions don't need to be aware of symlinks.
This is strictly a change in behavior, but the vfs_widelinks
module (if loaded) copes with symlinks in the share definition.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Widelinks are now always denied, unless the vfs_widelinks
VFS module is loaded.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Widelinks are now always denied, unless the vfs_widelinks
VFS module is loaded.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
As the widelinks logic is now moving into a
vfs_widelinks module, we need to custom load
it after the default module is initialized.
That way no changes to smb.conf files are
needed.
We may revisit this for Samba 5.0 and force
people to change their smb.conf files and
explicitly load this as a vfs module if they
want the insecure widelinks behavior.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
