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 logic to parse DNS value strings (e.g. "example.com 10" for an MX,
which needs to be split on the space) is repeated at least in
samba-tool dns and tests/dcerpc/dnsserver.py. Here we bring it
together so we can do it once.
The sep= keyword allows callers to separate on all runs of
whitespace (the default, as samba-tool dns does) or, using sep='', to
separate on true spaces only.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
We used to do something wrong with the refcounts, but we don't anymore,
so we don't need this confusing nonsense.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
The replaced comment was about a long fixed Python reference counting bug.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Everything else is TXTRecord, SRVRrcord, SOARecord.
Making CNAME the same allows easier lookups.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
smb_vfs_call_fset_dos_attributes is looking for the wrong function
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Issue:
We have a scenario where an application sends a Compound Related chain
consisting of:
SMB2_CREATE
SMB2_IOCTL
SMB2_SET_INFO
SMB2_CLOSE
SMB2_CREATE failed with NT_STATUS_ACCESS_DENIED and subsequent
requests all fail. In Samba they return NT_STATUS_FILE_CLOSED.
When I tried the same against a Win2k12 server, I noticed that all the
failed requests of the chain would return NT_STATUS_ACCESS_DENIED.
I believe this behaviour is also mentioned in the [MS-SMB2] Specs
3.3.5.2.7.2: Handling Compounded Related Requests
"When the current operation requires a FileId and the previous
operation either contains or generates a FileId, if the previous
operation fails with an error, the server SHOULD<223> fail the current
operation with the same error code returned by the previous
operation."
Fix:
Save NTATUS of a failed Create request. When we process subsequent
requests of the chain we check if the previous Create has failed. In
case of a Create failure we returned the saved NTSTATUS.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-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 8 17:30:50 UTC 2021 on sn-devel-184
This test verifies that if a compound related request is not preceeded by a
request that generates or contains a File-ID, the request fails with
NT_STATUS_INVALID_PARAMETER.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This verifies that if the initial create fails with
NT_STATUS_OBJECT_NAME_NOT_FOUND, compount related operations fail with the same
error.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We want to verify what Windows does when the first request of the
chain has failed and an async request is part of the chain. We see
Windows fails the async request with the same error. Also the async
request is immediately failed.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This test case checks what happens when we have an intermediate request
failure and how it impacts rest of the chain.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We already pass samba3.smb2.compound.related5, but mark related4 as knownfail.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-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): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Apr 7 17:32:07 UTC 2021 on sn-devel-184
The last user of SMB_VFS_REMOVEXATTR() is gone, I can now
remove the internal VFS functions implementing it.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We know this is safe as SMB_VFS_SYS_ACL_DELETE_DEF_FILE() is only
ever called on an fsp->fsp_name.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Note that now we're doing this by handle
not by pathname we must do it on the base_fsp,
as we have to remove the actual xattr on the base file.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Change SMB_VFS_NEXT_REMOVEXATTR() -> SMB_VFS_NEXT_FREMOVEXATTR().
It doesn't need to do STAT calls, it's always called
with an fsp->fsp_name smb_filename. This will change
later to a handle-based call.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Ensure it only uses an io fd for a handle based call.
Otherwise fall back to pathname based. This is the same as the
fallback used in vfs_default.c
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Ensure it only uses an io fd for a handle based call.
Otherwise fall back to pathname based. This is the same as the
fallback used in vfs_default.c
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Changes use of SMB_VFS_REMOVEXATTR() -> SMB_VFS_FREMOVEXATTR().
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This means adding a synthetic_pathref() call into the
nfs4acl_xattr version of SMB_VFS_GET_NT_ACL_AT() which
is the pathname-based ACL fetch call.
One place where this (smb_fname->fsp == NULL)
can happen is from open when checking parent
directory ACL - check_parent_access() currently
isn't always passed a smb_fname with a valid
fsp and check_parent_access() currently doesn't
open a pathref smb_fname->fsp itself (eventually
it should be passed in a pathref from the caller).
There are also a few other places inside smbd
that call smbd_check_access_rights() also without
a pathref fsp.
This check should be moved into the
callers inside smbd to ensure that smb_fname->fsp
is always valid here, and in a later patchset (not
part of this set) I will do just that.
Ultimately it may be possible to remove
pathname based SMB_VFS_GET_NT_ACL_AT(), this
requires further investigation.
But until then, we need this change.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We know that the parent name must
exist, and the name has been canonicalized
even if this was a POSIX pathname.
Ensure that we follow symlinks for
the parent. See the torture test
POSIX-SYMLINK-PARENT for details.
Remove knownfail entry.
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 7 15:39:45 UTC 2021 on sn-devel-184
This creates a directory, then a symlink to a directory,
and then checks we can POSIX create and delete file, directory,
symlink and hardlink filesystem objects under the symlink
parent directory.
Mark as knownfail until next commit.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Apr 7 10:24:17 UTC 2021 on sn-devel-184
