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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Hides symlinks from smbd. Will be used to replace
the lp_widelinks() code inside smbd.
Long description of how this module works
with notes is included.
The man page and WHATSNEW.txt update is done
in a later patch in this series.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Craft core structures to dispatch local calls in the same way as remote
ones, removing the special handling in the autogenerated code.
This is also necessary to drop s3 rpc handles implementation.
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Apr 8 22:23:05 UTC 2020 on sn-devel-184
We now have the check of the real connection's prootocol, so the
smb.conf's "client min protocol" does not really matter here
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
