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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As we currently don't attempt to cancel the internal aio request, we
must ignore the SMB2 cancel request and continue to process the SMB2
request, cf MS-SM2 3.3.5.16:
If the target request is not successfully canceled, processing of the
target request MUST continue and no response is sent to the cancel
request.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13667
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is the final step in implementing the needed macOS semantics on the
FinderInfo stream: as long as the client hasn't written a non-zero
FinderInfo blob to the stream, there mustn't be a visible filesystem
entry for other openers.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
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 Nov 1 01:14:23 CET 2018 on sn-devel-144
One to rule them all: consistently test critical operations on all
streams relevant to macOS clients: the FinderInfo stream, the Resource
Fork stream and an arbitrary stream that macOS maps to xattrs when
written to on a macOS SMB server.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
First step in achieving macOS compliant behaviour wrt to empty streams:
- hide empty streams in streaminfo
- prevent opens of empty streams
This means that we may carry 0-byte sized streams in our streams
backend, but this shouldn't really hurt.
The previous attempt of deleting the streams when an SMB setinfo eof to
0 request came in, turned out be a road into desaster.
We could set delete-on-close on the stream, but that means we'd have to
check for it for every write on a stream and checking the
delete-on-close bits requires fetching the locking.tdb record, so this
is expensive and I'd like to avoid that overhead.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
o Adds checks verifying that after setting eof to 0 on a stream, a
subsequent open gets ENOENT, before and after closing the handle that
had been used to set eof to 0.
o Verify that a write to a handle succeeds after that handle has been
used to set eof to 0 on a stream.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
macOS SMB server versions supports this since 10.12, so we adapt our
behaviour.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
While this operation failed against older macOS versions, it passes
against versions 10.12 and newer. Update the test accordingly, a
subsequent commit will then update our implementation.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13646
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Rename the parameter names and adjust the return codes from dn_compare
so that:
dn_compare(a, b) =>
LESS_THAN means a is less than b.
GREATER_THAN means a is greater than b.
Thanks to metze for suggesting the correct semantics for dn_compare
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13664
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The group audit code incorrectly logs member additions and deletions.
Thanks to metze for the debugging that isolated the issue, and for
suggesting the fix to dn_compare.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13664
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is important, otherwise we'll loose the <SID=> component of the
linked attribute.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13418
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This will be used by dbcheck in the next commits.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13418
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This demonstrates the bug, that happens when the primaryGroupID
of a user is changed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13418
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Correctly handle "ldb://" and "mdb://" schemes in the file path when
determining the path for the encrypted secrets key file.
When creating a new user and specifying the local file path of the
sam.ldb DB, it was possible to create an account that you could not
login with. The path for the key file was incorrectly calculated
for the "ldb://" and "mdb://" schemes, the scheme was not stripped from
the path and the subsequent open of the key file failed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13653
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Oct 19 09:34:46 CEST 2018 on sn-devel-144
When creating a new user and specifying the local file path of the
sam.ldb DB, it's possible to create an account that you can't actually
login with.
This commit contains tests to verify the bug.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13653
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Add the 'reveal_internals' controls when performing objectclass-based
checks of mandatory attributes. This prevents the extended_dn DSDB
module from suppressing attributes that point to deleted (i.e.
non-existent/expunged) objects.
This ensures that, when modifying an object (and often not even
touching the mandatory attribute) that the fact that an attribute is a
DN, and the DN target is deleted, that the schema check will still pass.
Otherwise a fromServer pointing at a dead server can cause failures,
i.e. you can't modify the affected object at all, because the DSDB
thinks a mandatory attribute is missing.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13621
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
The fromServer attribute is slightly unique, in that it's a DN (similar
to a one-way link), but it is also a mandatory attribute.
Currently, if fromServer gets a bad value (i.e. a dead server that has
been expunged), the DSDB rejects any attempts to modify the associated
nTDSConnection object (regardless of whether or not you're actually
changing the fromServer attribute).
This patch adds a test-case that demonstrates how the DB can get into
such a state.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13621
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Currently the whole conversion is skipped if the FinderInfo entry in the
AppleDouble file is of the default size (ie not containing xattrs).
That also means we never converted FinderInfo from the AppleDouble file
to stream format. This change finally fixes this.
Note that this keeps failing with streams_depot, much like the existing
known-fail of "samba3.vfs.fruit streams_depot.OS X AppleDouble file
conversion". Fixing the conversion to work with vfs_streams_depot is a
task for another day.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13649
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Oct 11 01:30:13 CEST 2018 on sn-devel-144
This testcase demonstrates that the AppleDouble conversion in vfs_fruit
doesn't correctly convert the FinderInfo data from the AppleDouble file
to a stream.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13649
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The STATUS_SESSION_EXPIRED error was returned unencrypted,
if the request was encrypted.
If clients use SMB3 encryption and the kerberos authenticated session
expires, clients disconnect the connection instead of doing a reauthentication.
From https://blogs.msdn.microsoft.com/openspecification/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective/
The sender encrypts the message if any of the following conditions is
satisfied:
- If the sender is sending a response to an encrypted request.
- If Session.EncryptData is TRUE and the request or response being
sent is not NEGOTIATE.
- If Session.EncryptData is FALSE, the request or response being sent
is not NEGOTIATE or SESSION_SETUP or TREE_CONNECT, and
<TreeConnect|Share>.EncryptData is TRUE.
[MS-SMB2] 3.3.4.1.4 Encrypting the Message
If Connection.Dialect belongs to the SMB 3.x dialect family and
Connection.ClientCapabilities includes the SMB2_GLOBAL_CAP_ENCRYPTION
bit, the server MUST encrypt the message before sending, if any of the
following conditions are satisfied:
- If the message being sent is any response to a client request for which
Request.IsEncrypted is TRUE.
- If Session.EncryptData is TRUE and the response being sent is not
SMB2_NEGOTIATE or SMB2 SESSION_SETUP.
- If Session.EncryptData is FALSE, the response being sent is not
SMB2_NEGOTIATE or SMB2 SESSION_SETUP or SMB2 TREE_CONNECT, and
Share.EncryptData for the share associated with the TreeId in the SMB2
header of the response is TRUE.
The server MUST encrypt the message as specified in section 3.1.4.3,
before sending it to the client.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13624
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Tue Oct 2 14:11:30 CEST 2018 on sn-devel-144
This reproduces the problem we have with expired encrypted sessions.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13624
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
When a new DC is joined to the domain, samba-tool would automatically
detect an appropriate site for the new DC. However, it only did this if
the --server option wasn't specified. The new DC's site got
automatically updated as part of the finddc() work, however, this step
gets skipped if we already know the server DC to join to.
In other words, if Default-First-Site-Name doesn't exist and you specify
--server in the join, then you have to also specify --site manually,
otherwise the command fails. This is precisely what's happening in the
join_ldapcmp.sh test, now that the backupfromdc testenv no longer has the
Default-First-Site-Name present.
This patch adds a new find_dc_site() function which uses the same
net.finddc() API (except based on the server-address rather than
domain-name). Assigning DEFAULTSITE has been moved so that it only
gets done if finddc() can't determine the site.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Recent changes around restoring a domain that lacked
Default-First-Site-Name highlighted a problem. Normally when you join a
DC to a domain, samba-tool works out the correct site to use
automatically. However, if the join uses '--server' to select a DC, then
this doesn't work. It defaults back to Default-First-Site-Name, and the
join command fails if this site doesn't exist.
All the testenvs had Default-First-Site-Name present, so this was never
tested. Now the backupfromdc no longer has a Default-First-Site-Name
site, so running a simple join against that DC fails, highlighting the
problem.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
There are 2 different PSO tests:
- make test TESTS=ldap.password_settings
- make test TESTS=samba_tool.passwordsettings
There's also another test that's completely unrelated to PSOs:
- make test TESTS=blackbox.password_settings
This patch renames ldap.password_settings --> ldap.passwordsettings.
This means 'make test TESTS=passwordsettings' will run both PSO tests,
but not the unrelated blackbox test.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Sep 21 22:58:17 CEST 2018 on sn-devel-144
Since scavenging is implemented the samba_dnsupdate command always updates all
dns records required by the dc. This is not needed if dns zone scavenging
is not enabled.
This avoids the repeating TSIG error messages:
# samba_dnsupdate --option='dns zone scavenging = yes' 2>&1 | uniq -c
29 ; TSIG error with server: tsig verify failure
1 Failed update of 29 entries
# echo ${PIPESTATUS[0]}
29
# samba_dnsupdate --option='dns zone scavenging = no' 2>&1 | uniq -c
# echo ${PIPESTATUS[0]}
0
Note that this results in about 60 lines in the log file,
which triggered every 10 minutes ("dnsupdate:name interval=600" is the default).
This restores the behavior before 8ef42d4dab4dfaf5ad225b33f7748914f14dcd8c,
if "dns zone scavenging" is not switched on (which is still the default).
Avoiding the message from happening at all is subject for more debugging,
most likely they are caused by bugs in 'nsupdate -g' (from the bind package).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13605
Pair-programmed-with: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Björn Baumbach <bb@sernet.de>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Björn Baumbach <bb@sernet.de>
Autobuild-Date(master): Wed Sep 12 18:03:10 CEST 2018 on sn-devel-144
This changes behaviour flagged as being for Java 1.6. My hope is that this does not
set f.canonicalize
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
The ability the kinit with an SPN (not also being a UPN) has gone away as
windows doesn't offer this functionality.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
The failures in this test compared with Windows Server 1709 are added to
knownfail.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
This reverts commit 20dc68050df7b1b0c9d06f8251183a0a6283fcaf.
Tests (the krb5.kdc testsuite) show this behaviour is incorrect.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
The krb5.kdc.canon testsuite has been updated to pass against Windows
Server 1709 in four modes:
* A normal user
* A user with a UPN
* A user with an SPN (machine account)
* A user with an SPN as the UPN
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Salt principal for the interdomain trust is krbtgt/DOMAIN@REALM where
DOMAIN is the sAMAccountName without the dollar sign ($)
The salt principal for the BLA$ user object was generated wrong.
dn: CN=bla.base,CN=System,DC=w4edom-l4,DC=base
securityIdentifier: S-1-5-21-4053568372-2049667917-3384589010
trustDirection: 3
trustPartner: bla.base
trustPosixOffset: -2147483648
trustType: 2
trustAttributes: 8
flatName: BLA
dn: CN=BLA$,CN=Users,DC=w4edom-l4,DC=base
userAccountControl: 2080
primaryGroupID: 513
objectSid: S-1-5-21-278041429-3399921908-1452754838-1597
accountExpires: 9223372036854775807
sAMAccountName: BLA$
sAMAccountType: 805306370
pwdLastSet: 131485652467995000
The salt stored by Windows in the package_PrimaryKerberosBlob
(within supplementalCredentials) seems to be
'W4EDOM-L4.BASEkrbtgtBLA' for the above trust
and Samba stores 'W4EDOM-L4.BASEBLA$'.
While the salt used when building the keys from
trustAuthOutgoing/trustAuthIncoming is
'W4EDOM-L4.BASEkrbtgtBLA.BASE', which we handle correct.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13539
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Sep 5 03:57:22 CEST 2018 on sn-devel-144
This demonstrates the bug we currently have.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13539
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This makes sure we don't treat trusted domains in the same way we treat
our primary domain.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11517
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This avoids a race in durable handle reconnects if the reconnect comes
in while the old session is still in the tear-down phase.
The new session is supposed to rendezvous with and wait for destruction
of the old session, which is internally implemented with
dbwrap_watch_send() on the old session record.
If the old session deletes the session record before calling
file_close_user() which marks all file handles as disconnected, the
durable handle reconnect in the new session will fail as the records are
not yet marked as disconnected which is a prerequisite.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13549
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The original fix for bug 13441 was missing a check that verifies that
fruit_ftruncate() is actually called on a stream.
Follow-up to
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13441
Pair-Programmed-With: Volker Lendecke <vl@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Aug 23 15:28:48 CEST 2018 on sn-devel-144
A user that doesn't have access to view an attribute can still guess the
attribute's value via repeated LDAP searches. This affects confidential
attributes, as well as ACLs applied to an object/attribute to deny
access.
Currently the code will hide objects if the attribute filter contains an
attribute they are not authorized to see. However, the code still
returns objects as results if confidential attribute is in the search
expression itself, but not in the attribute filter.
To fix this problem we have to check the access rights on the attributes
in the search-tree, as well as the attributes returned in the message.
Points of note:
- I've preserved the existing dirsync logic (the dirsync module code
suppresses the result as long as the replPropertyMetaData attribute is
removed). However, there doesn't appear to be any test that highlights
that this functionality is required for dirsync.
- To avoid this fix breaking the acl.py tests, we need to still permit
searches like 'objectClass=*', even though we don't have Read Property
access rights for the objectClass attribute. The logic that Windows
uses does not appear to be clearly documented, so I've made a best
guess that seems to mirror Windows behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Currently Samba is a bit disclosive with LDB_OP_PRESENT (i.e.
attribute=*) searches compared to Windows.
All the acl.py tests are based on objectClass=* searches, where Windows
will happily tell a user about objects they have List Contents rights,
but not Read Property rights for. However, if you change the attribute
being searched for, suddenly the objects are no longer visible on
Windows (whereas they are on Samba).
This is a problem, because Samba can tell you about which objects have
confidential attributes, which in itself could be disclosive.
This patch adds a acl.py test-case that highlights this behaviour. The
test passes against Windows but fails against Samba.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
