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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Avoid the dependency on global->db_rec. This makes the callers more
verbose, but it makes the data dependencies much more obvious. This
will enable removing smbXsrv_open_global0->db_rec at some point.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We don't need anything cryptographic for persistent file handle ids
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15302
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Sat Feb 11 08:48:05 UTC 2023 on atb-devel-224
source3/smbd/msdfs.c:367:14: error: explicitly assigning value of variable of
type 'char *' to itself [-Werror,-Wself-assign]
servicename = servicename;
~~~~~~~~~~~ ^ ~~~~~~~~~~~
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Don't depend on the record to be passed in, return NTSTATUS. The two
flags were a bit confusing to me, now NT_STATUS_OK means "found a
valid record with a live process", and NT_STATUS_FATAL_APP_EXIT means
we found a stale record from a crashed smbd
Signed-off-by: Volker Lendecke <vl@samba.org>
This isn't exactly rocket science we would need to keep around
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Move allocation of smbXsrv_open_global0 out of
smbXsrv_open_global_allocate()
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This moves the bit-fiddling right next to the check we do,
"global_zeros" was only used for this one purpose and its assignment
was a few lines away.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
vfs_virusfilter expects a non-NULL fsp->fsp_name to use for printing debugs
(it always indirects fsp->fsp_name). vfs_fruit also does the same, so would
also crash in fruit_close() with 'debug level = 10' and vfs_default:VFS_OPEN_HOW_RESOLVE_NO_SYMLINKS = no
set (we don't test with that which is why we haven't noticed
this before).
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15283
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Fri Jan 13 08:33:47 UTC 2023 on sn-devel-184
As these functions can implicitly call reply_nterror(..., NT_STATUS_INVALID_HANDLE)
they should never be available to SMB2 code paths.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Wed Jan 11 08:17:04 UTC 2023 on sn-devel-184
check_fsp_ntquota_handle() is called from SMB2 codepaths as
well as from SMB1. Even in the SMB1 cases the callers of
check_fsp_ntquota_handle() handle sendng the error packet when
check_fsp_ntquota_handle returns false so on a 'return false'
we'd end up sending an error packet twice.
The SMB2 callers of check_fsp_ntquota_handle()
already check that fsp is valid, so there's
no danger of us sending an SMB1 error packet
over the SMB2 stream (so I'm not classing
this as a bug to be back-ported).
Fix check_fsp_ntquota_handle() by inlineing
the check_fsp_open() functionality without
the reply_nterror() calls.
This will allow the next commit to move check_fsp_open()
with the implicit reply_nterror() and also check_fsp()
(which calls check_fsp_open()) into the SMB1 smb1_reply.c
file as SMB1-only code.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Volatile file handle IDs are purely per-process, in fact we used a
dbwrap_rbt for this. To get a unique ID we however have the
specialized idtree data structure, we don't need to repeat the
allocation algorithm that already exists there.
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): Tue Jan 10 01:23:38 UTC 2023 on sn-devel-184
This was only referenced in smbXsrv_open_close, but it was never
assigned anything but NULL.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This should really not happen, crashing would be the right response.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This changes the talloc hierarchy for a few callers, but as
talloc_tos() was initially designed exactly for this purpose (printing
SIDs in DEBUG), it should be okay.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Even const arrays of const strings need to be relocated at startup time.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Jan 5 18:00:17 UTC 2023 on sn-devel-184
The SMB_REALLOC macro properly deals with failure to realloc, so
overwriting the target variable is correct here.
Signed-off-by: Volker Lendecke <vl@samba.org>
This is a bit more involved as readdir_attr_data needs to be looked
at. The meaning of this if-statements should be the same though,
readdir_attr_data can only be non-NULL if we don't have a reparse
point around. See the beginning of smbd_marshall_dir_entry().
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Jan 4 09:48:37 UTC 2023 on sn-devel-184
