This checkin ensures all objects allocated by jndi requests are freed up. It does this by wrapping NamingEnumerations with a ClosableNamingEnumeration that is placed in a try-with-resources block.
Original commit: elastic/x-pack-elasticsearch@8bed9585bd
A range is provided for the client profile and the test assumes that the first
port in the range is the port that the transport is bound to, which is not always
true. This change makes the test use the actual port that the client profile is
bound to.
Closeselastic/elasticsearch#531
Original commit: elastic/x-pack-elasticsearch@05962702ed
Hostname verification was previously randomized on a per node level, when it really
should have been a cluster level setting. This change makes hostname verification
randomization a cluster level settings.
Original commit: elastic/x-pack-elasticsearch@2a7da8aaf1
Since the system privilege also mapped to cluster/index monitoring actions, the access granted on those was only logged in `TRACE` level. This commit makes sure that these actions will be treated as any of the other actions, and only keep the *internal* system calls under `TRACE`
Fixeselastic/elasticsearch#554
Original commit: elastic/x-pack-elasticsearch@ffb719f547
Adds a functional test to check for cluster level privileges
Closes elasticsearch/elasticsearch-shield-qaelastic/elasticsearch#11
Original commit: elastic/x-pack-elasticsearch@dd79614c24
We have two ways of resolving wildcards in shield:
1) expanding them to matching authorized indices for the current user, which is used for every request that implements `IndicesRequest.Replaceable`, giving to wildcards a different meaning in the context of shield, abnd replacing the resolved names to the request on the coordinating node.
2) resolving them as es core would by default: we do this only for `IndicesAliasesRequest` since it's the only request that supports wildcards but doesn't allow to replace its indices. This is done on every node that processes the request, no replacement to the request takes place.
Shard/node level requests are a bit of a special case though since they could potentially contain wildcards. They hold the original indices and indices options, thus they effectively support wildcards, but given that wildcards always get replaced on the coordinating node even before shard/node level requests get created, we are sure they will never contain wildcards. Hence we should never even try to explode their wildcards, since they can't contain any.
We should make the above distinctions clearer in code by:
1) having an assert that verifies the IndicesAliasesRequest special case
2) making sure that we explode wildcards as core would only for IndicesAliasesRequest, not touching shard/node level requests
3) adding an assert that verifies that shard/node level requests never contain wildcards
i
Also, the process of going over the indices by using MetaData#convertFromWildcards (what option 2 does) has one side effect other than wildcards resolution: it causes unnecessary exceptions in shield, exceptions that would be thrown by core anyway when needed after the authorization process. This happens because we try and reuse code taken from es core that does wildcards resolution plus indices validation at once (even if there were no wildcards among indices).
In general all of the user requests that support wildcards (based on their indices options) should have their indices replaced on the coordinating node (the only exception being IndicesAliasesRequest, see elastic/elasticsearch#112), using shield specific code. Their subsequent (internal) shard level requests will never contain wildcards. That's why there is no need to go over all of the indices when there's no wildcards, which would cause some needless validation to happen as well.
Side note: the additional validation step caused tribe node failures with requests against indices belonging to multiple tribes (the exact purpose of the tribe node). Each tribe complained because it didn't have all of the indices in its own cluster state, which is perfectly fine (think of `tribe1` that holds `index1` and `tribe2` that holds `index2`, when searching against both indices from a tribe node). Although this commit makes sure that we don't throw any index missing exception for indices that are not available, all of the tribes will still need to authorize the action on all of the indices (`tribe1` requires privileges for `index2` so does `tribe2` for `index1`, otherwise the shard level requests will get rejected.
Closeselastic/elasticsearch#541
Original commit: elastic/x-pack-elasticsearch@dd81ec0177
As es core requests don't implement `toString` at the moment, we can't just render them as they are. Instead, for transport messages we'll only render the class name, and for rest requests we'll render the content if there is one (a rest request without a content will be rendered as an empty string)
Original commit: elastic/x-pack-elasticsearch@fb14b41a28
The SignatureService tried to access the system key file in
the constructor, which could lead to endless loops. This PR
moves the service into a AbstractLifecycleComponent to keep
the constructor dumb.
Relates elastic/elasticsearch#517
Original commit: elastic/x-pack-elasticsearch@b1e5bfe98c
For LDAP hostname verification, we use the "default" SSLContext, which is cached in a map
and re-used. If a secure connection is established then the session is cached for use later. In
the tests, we sometimes run a test that connects without hostname verification and a SSL session
is cached. Then when the hostname verification test runs, it uses the cached session and does
not perform hostname verification causing the test to fail. This fix changes the test to always
use a new SSLContext for each test.
Closeselastic/elasticsearch#521
Original commit: elastic/x-pack-elasticsearch@46ffed34bb
When generating the sysemkey, the permissions are set to owner read/write
only in order to protect the system key. This only works, if the underlying
filesystem supports posix permissions.
Closeselastic/elasticsearch#516
Original commit: elastic/x-pack-elasticsearch@32d6e1d745
SSLEngine will throw various SSLExceptions when the application initiates a write prior
to the handshake being completed. The NettySecuredTransport marks a channel as ready
for use once it is connected, even though the handshake has not completed. A handler
has been added that performs the handshake and queues writes until the handshake has
completed. Additionally, fix SslMultiPortTests to always connect to the proper client
profile port.
Closeselastic/elasticsearch#390. Closeselastic/elasticsearch#393. Closeselastic/elasticsearch#394. Closeselastic/elasticsearch#395. Closeselastic/elasticsearch#414
Original commit: elastic/x-pack-elasticsearch@1bb3218373
Because elasticsearch core does not have a possibility to retrieve the
currently open search contexts across the cluster, there is no possiblity
to check if a user is allowed to close a context, when `_all` is
specified.
This commit introduces a new cluster privilege called
cluster:scroll/clear/_all
which allows to clear all scroll requests.
Closeselastic/elasticsearch#502
Original commit: elastic/x-pack-elasticsearch@5f5ce5de36
SSL and TLS do not require hostname verification, but without it they are susceptible
to man in the middle attacks. This adds support for hostname verification for
transport client connections and for ldaps connections.
Closeselastic/elasticsearch#489
Original commit: elastic/x-pack-elasticsearch@c9380f0319
This extends the connect timeout on windows to give it enought time to complete. It moves the ldap read timeout test to openldap and active directory.
We now have three timeouts configurable. The timeout tests on active directory only work for TCP connect, and TCP read, but not LDAP Search.
Original commit: elastic/x-pack-elasticsearch@ff97396f60
Because this leads to endless loops when starting elasticsearch
some components have been refactored to AbstractLifecycleComponents
so that the exception throwing logic can executed in the
`doStart()` method.
Closeselastic/elasticsearch#505
Original commit: elastic/x-pack-elasticsearch@75d1fd358a
As no test has been marked with the @Network annotation, the test should not
try to connect to example.com (which needs to be resolved and thus requires an
internet connection). We can simply bind a local socket and run into the 1ms
timeout there.
Original commit: elastic/x-pack-elasticsearch@2c2da90607
In order to be more flexible this clean up commit splits the
TransportService into a client and server one. As part of this
we can safely remove the slightly misused TransportFilters class.
Renamed shield.type from server to node, so we can differentiate between node2node and node2client communication.
Original commit: elastic/x-pack-elasticsearch@a3a2f9bf38
Fixes duplicate messages being logged on reload of the user_roles file. Add the realm name
to the logging on reload of the role mappings file since there can be a distinct file per
ldap/ad realm.
Closeselastic/elasticsearch#485
Original commit: elastic/x-pack-elasticsearch@90932fcec7
Until now the store implementations truncated the existing file and recreated it in-place.
This has problems with bigger files as the files may not yet have finished to be written,
when the WatchService tries to pick them up.
This commit fixes the problem by creating a temp file first to write the new roles or user files
and then moves it over. Also an atomic move is tried first, if the file system supports this.
Closeselastic/elasticsearch#477
Original commit: elastic/x-pack-elasticsearch@75894dd75d
Previously, we always used the keystore password as the key password, which does not
work if a user specifies a different password when generating the key with keytool. If the
key password is not specified, the keystore password will be used.
Closeselastic/elasticsearch#473
Original commit: elastic/x-pack-elasticsearch@8a6efdbf21
The realm documentation has a 'enabled' parameter to indicate whether the realm
should be used or not. This value is now being honored so that a realm can be disabled.
Closeselastic/elasticsearch#474
Original commit: elastic/x-pack-elasticsearch@3638a14c22
This moves the esvm files into dev-tools and collapses the settings with "." This will require the latest version of esvm 0.0.10. It combines the ldap and ad config into the same file.
Added readme to dev-tools/esvm
Original commit: elastic/x-pack-elasticsearch@dab9fa643d
In order to fix various issues with the SSL service, the following cleanups have been done
* Removed SSLServiceProvider and all the lazy loading magic
* Do not try to create an SSLContext in the constructor. According to Guice docs the constructor
should only be used ever for variable declarations but not business logic. This also fixes a nasty
OOM, in case an exception was thrown in the constructor, because Guice tried to recreate that class
in an endless loop
* Get responsibilities right (which resulted in this nasty lazy loading provider design).
The SSLService allows to create a SSLEngine at the time you need it, but you need to supply
specific configuration if you want it to instead of using the default configuration
and creating a SSLContext on startup like we did before.
All changes are internal.
Closeselastic/elasticsearch#454Closeselastic/elasticsearch#453
Original commit: elastic/x-pack-elasticsearch@7ca49f781c
The shield test infra already verifies that the plugin is loaded before each test, it makes little sense to check again in this specific test. Left the second part that tests the shield info endpoint and renamed the test method
Closeselastic/elasticsearch#423
Original commit: elastic/x-pack-elasticsearch@ac2d566c42
Build number maven plugin requires this info to retrieve the build number and make it available as a variable, which is then published through RestShieldInfoAction, which is currently null. This commit makes sure the build number gets currently published.
Closeselastic/elasticsearch#428
Original commit: elastic/x-pack-elasticsearch@0a2bc7646b
- where the licenses were enabled on any cluster event. Instead they should only be enabled either explicitly by the test or at start up.
- also modified `ShieldActionModule` to for `ShieldActionFilter` to be bound as an eager singleton (es core doesn't define the scope for the registered action filters)
Original commit: elastic/x-pack-elasticsearch@47ac0d2e6f
- Added a `LicenseService` to handle license feature enable/disable events
- LicenseEventNotifier is responsible for notifying the license events to whatever registered listeners that are interested in them
- In Shield, when a license is disabled for `shield` feature, we block all read operations (done in the `ShieldActionFilter`)
- Added initial documentation around licensing
Closeselastic/elasticsearch#347
Original commit: elastic/x-pack-elasticsearch@6ba7a10cd4
c-a-m
jaymode
uboness
Alexander Reelsen
javanna