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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The bad password count is supposed to limit the number of failed login
attempt a user can make before being temporarily locked out, but race
conditions between processes have allowed determined attackers to make
many more than the specified number of attempts. This is especially
bad on constrained or overcommitted hardware.
To fix this, once a bad password is detected, we reload the sam account
information under a user-specific mutex, ensuring we have an up to
date bad password count.
Derived from a similar patch to source3/auth/check_samsec.c by
Jeremy Allison <jra@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14611
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The bad password count is supposed to limit the number of failed login
attempt a user can make before being temporarily locked out, but race
conditions between processes have allowed determined attackers to make
many more than the specified number of attempts. This is especially
bad on constrained or overcommitted hardware.
To fix this, once a bad password is detected, we reload the sam account
information under a user-specific mutex, ensuring we have an up to
date bad password count.
Discovered by Nathaniel W. Turner.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14611
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Ensures crtime of the root of the share and a newly created
file crtime are different. Should help avoid mistakes like the
error fixed by the previous commit.
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 Sep 12 16:21:23 UTC 2022 on sn-devel-184
The test SMB1-DFS-PATHS was using the file ino number
to check for file identity, fetching it using cli_qfileinfo_basic().
This works for SMB2, but the info level used by this for SMB1
(SMB_QUERY_FILE_ALL_INFO) doesn't return the ino number, so
all comparisons were succeeding as zero.
Change to using crtime (create time) for identity comparison
instead. This fix is mostly a rename of ino -> crtime, with
some changes around the tests and printf on error, but it
is easier to do in one go.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Sep 12 02:29:32 UTC 2022 on sn-devel-184
We have a list of ip addresses, so we can request them
all together under a single timeout, instead of asking
each ip with it's own timeout.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Thu Sep 8 08:12:46 UTC 2022 on sn-devel-184
For loop accesses entry->next after entry
has been removed from list in glfs_clear_preopened().
Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Sep 7 19:40:17 UTC 2022 on sn-devel-184
This code is young enough to justify a README.Coding patch, at least
IMO.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
rather than an NTStatusError, which is harder to decipher, and which
carries less information (namely, not the name of the problematic file).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14937
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
rather than an NTStatusError, which is harder to decipher, and which
carries less information (namely, not the name of the problematic
file).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14937
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If a client disconnected all its interfaces and reconnects when
the come back, it will likely start from any ip address returned
dns, which means it can try to connect to a different ctdb node.
The old node may not have noticed the disconnect and still holds
the client_guid based smbd.
Up unil now the new node returned NT_STATUS_NOT_SUPPORTED to
the SMB2 Negotiate request, as messaging_send_iov[_from]() will
return -1/ENOSYS if a file descriptor os passed to a process on
a different node.
Now we tell the other node to teardown all client connections
belonging to the client-guid.
Note that this is not authenticated, but if an attacker can
capture the client-guid, he can also inject TCP resets anyway,
to get the same effect.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15159
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Sep 2 20:59:15 UTC 2022 on sn-devel-184
This demonstrates that a client-guid connected to ctdb node 0
caused a connection with the same client-guid to be rejected by
ctdb node 1. Node 1 rejects the SMB2 Negotiate with
NT_STATUS_NOT_SUPPORTED, because passing the multi-channel connection
to a different node is not supported.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15159
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
1) Added debug messages in lib_vxfs.c for get, set and list attr functions
2) Removed vxfs_clearwxattr_fd and vxfs_clearwxattr_path code since it is no longer required now.
3) Replaced strcasecmp with vxfs_strcasecmp
4) Changed vxfs_fset_xattr to retain security.NTACL attribute
5) Fixed deny permissions not retained for a file created on CIFS share in vxfs_set_xattr
Signed-off-by: Saurabh Singh <saurabh.singh@veritas.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Sep 2 17:40:00 UTC 2022 on sn-devel-184
smbtorture3 test is: SMB1-DFS-PATHS
Tests open, and then all 4 methods of renaming/hardlinking
files:
1). SMBmv
2). SMBtrans2 SETPATHINFO
3). SMBtrans2 SETFILEINFO
4). SMBntrename
Also added a test for SMB1findfirst.
smbtorture3 test is: SMB1-DFS-SEARCH-PATHS.
What this shows is that Windows strips off the
SMB1findfirst mask *before* calling the DFS path
parser (smbd currently does not).
Added so we know how to fix the server code to match Windows
behavior in parsing DFS paths in different calls going forward.
Passes fully against Windows. Adds knownfails for smbd.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
This is what a Windows server returns. Tested with a share residing on a FAT
formatted drive, a Windows filesystem that doesn't support streams.
Combinations tested:
file::$DATA
file:stream
file:stream:$DATA
All three fail with NT_STATUS_OBJECT_NAME_INVALID.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15126
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15161
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
We're not doing anything with this yet, this is just to provide a test
counterpart. Protected by -DDEVELOPER and "smb3 unix extensions = yes"
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This is an extension of the create() function allowing smb2 create
contexts to be passed back and forth and also returning the
smb_create_returns. A new function seemed necessary for me because we
need to return not just the fnum. So I chose a 3-tuple, see the test
for an example how to use this.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Make sure we do and don't announce posix depending on "smb3 unix
extensions" parameter
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Only available in DEVELOPER builds. Adding now to get some testing
step by step done.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Passes fully against Windows.
This shows that DFS paths on Windows on SMB2 must
be of the form:
SERVER\SHARE\PATH
but the actual contents of the strings SERVER and
SHARE don't need to match the given server or share.
The algorithm the Windows server uses is the following:
Look for a '\\' character, and assign anything before
that to the SERVER component. The characters in this
component are not checked for validity.
Look for a second '\\' character and assign anything
between the first and second '\\' characters to the
SHARE component. The characters in the share component
are checked for validity, but only ':' is flagged as
an illegal sharename character despite what:
[MS-FSCC] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/dc9978d7-6299-4c5a-a22d-a039cdc716ea
says.
Anything after the second '\\' character is assigned
to the PATH component and becomes the share-relative
path.
If there aren't two '\\' characters it removes
everything and ends up with the empty string as
the share relative path.
To give some examples, the following pathnames all map
to the directory at the root of the DFS share:
SERVER\SHARE
SERVER
""
ANY\NAME
ANY
::::\NAME
the name:
SERVER\:
is illegal (sharename contains ':') and the name:
ANY\NAME\file
maps to a share-relative pathname of "file",
despite "ANY" not being the server name, and
"NAME" not being the DFS share name we are
connected to.
Adds a knownfail for smbd as our current code
in parse_dfs_path() is completely incorrect
here and tries to map "incorrect" DFS names
into local paths. I will work on fixing this
later, but we should be able to remove parse_dfs_path()
entirely and move the DFS pathname logic before
the call to filename_convert_dirfsp() in the
same way Volker suggested and was able to achieve
for extract_snapshot_token() and the @GMT pathname
processing.
Also proves the "target" paths for SMB2_SETINFO
rename and hardlink must *not* be DFS-paths.
Next I will work on a torture tester for SMB1
DFS paths.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reivewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 30 17:10:33 UTC 2022 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14215
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): Mon Aug 29 18:20:20 UTC 2022 on sn-devel-184
We need to update the btime of fsp->fsp_name->st.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14215
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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): Sun Aug 28 20:58:57 UTC 2022 on sn-devel-184
