WIldcard IndicesPermissions don't cover .security #36765

albertzaharovits · 2018-12-18T12:53:56Z

.security and .security-6 have to be named explicitly when defining IndicesPrivileges .

Previously, granting privileges over the * index pattern, would have granted privileges over .security as well. However, even if technically a role had privileges over .security access to this index would be further restricted to only the superuser role. This PR changes this, such that when a role defines indices privileges over .security (by listing it explicitly) it will grant access without further limitations.

For example, the superuser role's IndicesPrivileges changed from:

new RoleDescriptor.IndicesPrivileges[] { 
  RoleDescriptor.IndicesPrivileges.builder().indices("*").privileges("all").build()
}

to

new RoleDescriptor.IndicesPrivileges[] { 
  RoleDescriptor.IndicesPrivileges.builder().indices("*").privileges("all").build(),
  RoleDescriptor.IndicesPrivileges.builder().indices(".security", ".security-6").privileges("all").build()
}

elasticmachine · 2018-12-18T12:53:58Z

Pinging @elastic/es-security

albertzaharovits · 2018-12-18T12:59:34Z

...in/security/src/main/java/org/elasticsearch/xpack/security/support/SecurityIndexManager.java

-    public static List<String> indexNames() {
-        return Collections.unmodifiableList(Arrays.asList(SECURITY_INDEX_NAME, INTERNAL_SECURITY_INDEX));
-    }
-


These lines are responsible for most of the changes. Security index names had to be moved from x-pack:plugin:security to x-pack:plugin:core . I have created org.elasticsearch.xpack.core.security.index.SystemIndicesNames.

jaymode · 2018-12-18T18:47:04Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

-            }
-            return indexMatcher(indices);
-        };
+        this.systemIndicesAutomaton = Automatons.patterns(SystemIndicesNames.indexNames());


why not make this a static final instance?

I had moved it as a class member 👍

At some point I wanted to guard all Automatons construction with the failure handler with the verbose exception message but gave up and forgot to change this.

jaymode · 2018-12-18T19:30:44Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

+            }
+        }
+        try {
+            final Automaton exactMatchAutomaton = Automatons.patterns(exactMatch);


this drops the exact match optimization. Why do we do it this way?

Because we need it for testIndexMatch that is needed for "has privilege". In "has privilege" the user can check an index pattern (not only a concrete index as in the authorization use case), and we test this with the automaton subset operation. However, the exact optimization only works for predicates. The code for this has been copied from TransportHasPrivilegesAction and I agree it amounts to a great deal of complexity in this class.

Yet, I think it's the right approach to have the optimization for the "authorize" use case, and a cache-able automaton for the "has privilege" use case (even though the optimization partly aims to bypass automaton generation in the first place). "has privilege" should be rare, and we cannot avoid automatons in this case.

jaymode · 2018-12-18T19:31:54Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

@@ -148,6 +187,24 @@ public Automaton allowedActionsMatcher(String index) {
        return automatonList.isEmpty() ? Automatons.EMPTY : Automatons.unionAndMinimize(automatonList);
    }

+    public boolean testIndexMatch(String checkIndex, String checkPrivilegeName) {


Please add javadocs explaining what this is doing including why we cache groups to automatons

albertzaharovits · 2018-12-19T18:54:15Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

@@ -40,34 +44,30 @@
 * A permission that is based on privileges for index related actions executed
 * on specific indices
 */
-public final class IndicesPermission implements Iterable<IndicesPermission.Group> {
+public final class IndicesPermission {


groups() is sufficient to iterate over the groups (and that is preferable because it expresses ordering that is required in tests)

albertzaharovits · 2018-12-19T18:55:48Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java


    public static final IndicesPermission NONE = new IndicesPermission();
+    private static final Automaton systemIndicesAutomaton = Automatons.patterns(SystemIndicesNames.indexNames());


Just to check we're fine with building Automatons at class initialization.

I am fine with it since this is not going to be a big one

albertzaharovits · 2018-12-19T19:11:47Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java


+    private final ConcurrentMap<String, Predicate<String>> allowedIndicesMatchersForAction = new ConcurrentHashMap<>();
+    private final ConcurrentMap<Group, Automaton> indexGroupAutomatonCache = new ConcurrentHashMap<>();


This is needed for the "has privilege" API. Otherwise we would avoid dealing with automatons in favor of dealing with predicates only (needed for the authorize use case). Since has privilege is called less frequently we built predicates lazily.

I'd like to avoid another cache. We already have caching at the automata level. Maybe we could use this type of class within the group to implement the subset type functionality:

private static class NameMatcher implements Predicate<String> { private final Set<String> exactMatch; private final Set<String> nonExactMatch; private final Automaton automaton; private final CharacterRunAutomaton patternMatcher; private NameMatcher(Set<String> exactMatch, Set<String> nonExactMatch) { this.exactMatch = exactMatch; this.nonExactMatch = nonExactMatch; this.automaton = nonExactMatch.isEmpty() ? Automatons.EMPTY : Automatons.patterns(nonExactMatch); this.patternMatcher = Automatons.runAutomaton(automaton); } @Override public boolean test(String toTest) { return exactMatch.contains(toTest) || patternMatcher.run(toTest); } public boolean isSupersetOf(String value) { if (IndicesPermission.isIndexPattern(value)) { final Automaton valueAutomaton = Automatons.patterns(value); if (Operations.subsetOf(valueAutomaton, automaton)) { return true; } else if (exactMatch.isEmpty() == false) { // slow path Automaton encompassingAutomaton = Automatons.unionAndMinimize(Arrays.asList(automaton, Automatons.patterns(exactMatch))); return Operations.subsetOf(valueAutomaton, encompassingAutomaton); } return false; } else { return test(value); } } @Override public String toString() { return "NameMatcher for " + Stream.concat(exactMatch.stream(), nonExactMatch.stream()).collect(Collectors.joining("|")); } }

I am ok with not caching the complete automaton and only building the complete one in specific circumstances. I assume has_privilege is rare call. Alternatively, we could have a LazyInitializable member inside the Group (this is still caching, but not exposed). I would however put this all inside the Group and not create another class.

What do you say?

I haven't thought about this as much as the 2 of you, so I might be missing something, but under what circumstances would an exactMatch index pattern, ever return true for a wildcard has-privileges pattern?

all : index-001 would never imply read : index-*

I think this proposed NameMatcher can be smart enough to implement this strategy on isSupersetOf

if value in a plain string return test(value)

else return Operations.subsetOf(Automatons.patterns(value), this.automaton)

with whatever checks we need for restricted_indices

albertzaharovits · 2018-12-19T19:18:21Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

+            } else {
+                return false;
+            }
+        };


The predicate is splayed out like this to accommodate for the logging statement.

albertzaharovits · 2018-12-19T19:58:19Z

x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/user/XPackUser.java

@@ -20,7 +20,7 @@
    public static final Role ROLE = Role.builder(new RoleDescriptor(ROLE_NAME, new String[] { "all" },
            new RoleDescriptor.IndicesPrivileges[] {
                    RoleDescriptor.IndicesPrivileges.builder().indices("/@&~(\\.security.*)/").privileges("all").build(),
-                    RoleDescriptor.IndicesPrivileges.builder().indices(IndexAuditTrailField.INDEX_NAME_PREFIX + "-*")
+                    RoleDescriptor.IndicesPrivileges.builder().indices(SystemIndicesNames.AUDIT_INDEX_NAME_PREFIX + "-*")


We can simplify this when we remove index audit.

albertzaharovits · 2018-12-19T20:01:05Z

...src/main/java/org/elasticsearch/xpack/security/action/user/TransportHasPrivilegesAction.java

-    private static boolean testIndex(Automaton checkIndex, Automaton roleIndex) {
-        return Operations.subsetOf(checkIndex, roleIndex);
-    }
-


This moved to IndicesPermission

albertzaharovits · 2018-12-25T23:07:22Z

...ugin/security/src/main/java/org/elasticsearch/xpack/security/authz/AuthorizationService.java

            putTransientIfNonExisting(AuthorizationServiceField.INDICES_PERMISSIONS_KEY, indicesAccessControl);
+        } else {
+            throw denial(auditId, authentication, action, request, permission.names());


This has been moved inside IndicesPermission.Group#check .

jaymode

The changes needed to support this feel like we are hacking this in. I'll try to think of something else; maybe @tvernum could also provide thoughts.

jaymode · 2019-01-08T19:49:19Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

-    private final Function<String, Predicate<String>> loadingFunction;
-
-    private final ConcurrentHashMap<String, Predicate<String>> allowedIndicesMatchersForAction = new ConcurrentHashMap<>();
+    private static final Logger logger = LogManager.getLogger();


can you add the class to the getLogger call?

jaymode · 2019-01-08T21:03:06Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java


    public static final IndicesPermission NONE = new IndicesPermission();
+    private static final Automaton systemIndicesAutomaton = Automatons.patterns(SystemIndicesNames.indexNames());


I am fine with it since this is not going to be a big one

jaymode · 2019-01-08T21:05:25Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java


+    private final ConcurrentMap<String, Predicate<String>> allowedIndicesMatchersForAction = new ConcurrentHashMap<>();
+    private final ConcurrentMap<Group, Automaton> indexGroupAutomatonCache = new ConcurrentHashMap<>();


I'd like to avoid another cache. We already have caching at the automata level. Maybe we could use this type of class within the group to implement the subset type functionality:

private static class NameMatcher implements Predicate<String> { private final Set<String> exactMatch; private final Set<String> nonExactMatch; private final Automaton automaton; private final CharacterRunAutomaton patternMatcher; private NameMatcher(Set<String> exactMatch, Set<String> nonExactMatch) { this.exactMatch = exactMatch; this.nonExactMatch = nonExactMatch; this.automaton = nonExactMatch.isEmpty() ? Automatons.EMPTY : Automatons.patterns(nonExactMatch); this.patternMatcher = Automatons.runAutomaton(automaton); } @Override public boolean test(String toTest) { return exactMatch.contains(toTest) || patternMatcher.run(toTest); } public boolean isSupersetOf(String value) { if (IndicesPermission.isIndexPattern(value)) { final Automaton valueAutomaton = Automatons.patterns(value); if (Operations.subsetOf(valueAutomaton, automaton)) { return true; } else if (exactMatch.isEmpty() == false) { // slow path Automaton encompassingAutomaton = Automatons.unionAndMinimize(Arrays.asList(automaton, Automatons.patterns(exactMatch))); return Operations.subsetOf(valueAutomaton, encompassingAutomaton); } return false; } else { return test(value); } } @Override public String toString() { return "NameMatcher for " + Stream.concat(exactMatch.stream(), nonExactMatch.stream()).collect(Collectors.joining("|")); } }

jaymode · 2019-01-08T21:12:52Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

+            final Predicate<String> indicesPatternsPredicate = indicesPatternsPredicate(Arrays.asList(indices));
+            this.implicitlyAuthorizeMonitorSystemIndices = (action, index) -> {
+                return SystemIndicesNames.indexNames().contains(index) && IndexPrivilege.MONITOR.predicate().test(action)
+                        && indicesPatternsPredicate.test(index) && privilege.predicate().test(action);


if I understand correctly, we need the indicesPatternsPredicate to account for the fact that the indexNameMatcher will not grant access to the security indices if they were declared as a wildcard?

Correct.

This replaces the

if (!indicesAccessControl.isGranted()) { throw denial(auditId, authentication, action, request, permission.names()); } else if (hasSecurityIndexAccess(indicesAccessControl) && MONITOR_INDEX_PREDICATE.test(action) == false && isSuperuser(authentication.getUser()) == false) { // only the XPackUser is allowed to work with this index, but we should allow indices monitoring actions through for debugging // purposes. These monitor requests also sometimes resolve indices concretely and then requests them logger.debug("user [{}] attempted to directly perform [{}] against the security index [{}]", authentication.getUser().principal(), action, SecurityIndexManager.SECURITY_INDEX_NAME); throw denial(auditId, authentication, action, request, permission.names()); } else {

block in AuthorizationService.java .

jaymode · 2019-01-08T21:19:51Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java

+            if (implicitlyAuthorizeMonitorSystemIndices.test(action, index)) {
+                // we allow indices monitoring actions through for debugging purposes. These monitor requests resolve indices concretely and
+                // then requests them. WE SHOULD BREAK THIS BEHAVIOR
+                logger.debug("Granted monitoring passthrough for index [{}] and action [{}]", index, action);


we should consider logging the group as well

albertzaharovits · 2019-01-09T15:08:41Z

Thanks for looking again into this @jaymode !
I think the reason for IndicesPermission looking kludgy is that code has been moved from the TransportHasPrivileges and AuthorizationService. The move was done so that the pattern logic excluding .security be contained in a single class. IMO, moving authorization code to IndicesPermission is a better design even without considering the change targeted by this PR.

jaymode · 2019-01-11T16:24:19Z

I did some brief thinking and came up with the following (unfinished) that I think feels less hacky:

git diff
diff --git a/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java b/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java
index 4936071ee84..04e4298def6 100644
--- a/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java
+++ b/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java
@@ -32,6 +32,7 @@ import java.util.SortedMap;
 import java.util.concurrent.ConcurrentHashMap;
 import java.util.function.Function;
 import java.util.function.Predicate;
+import java.util.stream.Stream;
 
 import static java.util.Collections.unmodifiableMap;
 import static java.util.Collections.unmodifiableSet;
@@ -54,16 +55,19 @@ public final class IndicesPermission implements Iterable<IndicesPermission.Group
         this.groups = groups;
         loadingFunction = (action) -> {
             List<String> indices = new ArrayList<>();
+            boolean allowRestricted = false;
             for (Group group : groups) {
                 if (group.actionMatcher.test(action)) {
                     indices.addAll(Arrays.asList(group.indices));
+                    allowRestricted |= group.allowRestricted &&
+                        Stream.of(".security", ".security-6").anyMatch(group.indexNameMatcher);
                 }
             }
-            return indexMatcher(indices);
+            return indexMatcher(indices, allowRestricted);
         };
     }
 
-    static Predicate<String> indexMatcher(List<String> indices) {
+    static Predicate<String> indexMatcher(List<String> indices, boolean allowRestricted) {
         Set<String> exactMatch = new HashSet<>();
         List<String> nonExactMatch = new ArrayList<>();
         for (String indexPattern : indices) {
@@ -74,6 +78,8 @@ public final class IndicesPermission implements Iterable<IndicesPermission.Group
             }
         }
 
+        // nocommit handle allowRestricted. Maybe add as exact matches and if there is a Automata minus
+        // these values from it?
         if (exactMatch.isEmpty() && nonExactMatch.isEmpty()) {
             return s -> false;
         } else if (exactMatch.isEmpty()) {
@@ -232,6 +238,7 @@ public final class IndicesPermission implements Iterable<IndicesPermission.Group
         private final Predicate<String> actionMatcher;
         private final String[] indices;
         private final Predicate<String> indexNameMatcher;
+        private final boolean allowRestricted;
 
         public FieldPermissions getFieldPermissions() {
             return fieldPermissions;
@@ -245,9 +252,10 @@ public final class IndicesPermission implements Iterable<IndicesPermission.Group
             this.privilege = privilege;
             this.actionMatcher = privilege.predicate();
             this.indices = indices;
-            this.indexNameMatcher = indexMatcher(Arrays.asList(indices));
+            this.indexNameMatcher = indexMatcher(Arrays.asList(indices), false);
             this.fieldPermissions = Objects.requireNonNull(fieldPermissions);
             this.query = query;
+            this.allowRestricted = false; // nocommit
         }
 
         public IndexPrivilege privilege() {
@@ -275,6 +283,10 @@ public final class IndicesPermission implements Iterable<IndicesPermission.Group
         boolean hasQuery() {
             return query != null;
         }
+
+        boolean allowsRestrictedIndexAccess() {
+            return allowRestricted;
+        }
     }
 
     private static class DocumentLevelPermissions {

albertzaharovits · 2019-01-13T13:47:52Z

test this please

tvernum

I left some comments.
I think you're still planning to change the Predicate / Automaton setup in IndicesPermission, so I only did a partial review there. Let me know if I'm mistaken and it's ready for full review.

tvernum · 2019-01-16T03:20:04Z

...ck/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/RoleDescriptor.java

@@ -600,6 +613,11 @@ public IndicesPrivileges(StreamInput in) throws IOException {
            this.deniedFields = in.readOptionalStringArray();
            this.privileges = in.readStringArray();
            this.query = in.readOptionalBytesReference();
+            if (in.getVersion().onOrAfter(Version.V_6_7_0)) {


This is right for the end-goal when we backport this to 6.7, but it will cause BWC to fail when it is merged to master as 6.7 won't be including the boolean field in the stream yet.
We typically commit it as V_7_0_0 and then update it to V6_7_0 at time of backport.

tvernum · 2019-01-16T03:20:42Z

...ck/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/RoleDescriptor.java

+        // by default certain restricted indices are exempted when granting privileges, as they should generally be hidden for ordinary
+        // users. Setting this flag eliminates this special status, and any index name pattern in the permission will cover restricted
+        // indices as well.
+        private boolean allow_restricted_indices = false;


This should be camelCase not snake_case

tvernum · 2019-01-16T03:44:56Z

.../src/main/java/org/elasticsearch/xpack/core/security/authz/permission/IndicesPermission.java


+    private final ConcurrentMap<String, Predicate<String>> allowedIndicesMatchersForAction = new ConcurrentHashMap<>();
+    private final ConcurrentMap<Group, Automaton> indexGroupAutomatonCache = new ConcurrentHashMap<>();


I haven't thought about this as much as the 2 of you, so I might be missing something, but under what circumstances would an exactMatch index pattern, ever return true for a wildcard has-privileges pattern?

all : index-001 would never imply read : index-*

I think this proposed NameMatcher can be smart enough to implement this strategy on isSupersetOf

if value in a plain string return test(value)

else return Operations.subsetOf(Automatons.patterns(value), this.automaton)

with whatever checks we need for restricted_indices

tvernum · 2019-01-16T03:54:08Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

-                    RoleDescriptor.IndicesPrivileges.builder().indices("*").privileges("all").build()},
+                    RoleDescriptor.IndicesPrivileges.builder().indices("*").privileges("all").build(),
+                    RoleDescriptor.IndicesPrivileges.builder().indices(SystemIndicesNames.indexNames().toArray(new String[0]))
+                            .privileges("all").build() },


This should have allowRestrictedIndices(true)

albertzaharovits · 2019-01-16T17:35:25Z

I'm going to open a separate PR for the allow_restricted_indices, there isn't much to keep out of this one. It will be simpler too! (I have ACKed all reviews, - thanks Jay and Tim!).

albertzaharovits · 2019-01-17T17:02:08Z

I have opened #37577 which supersedes this one.
This one got too cluttered, and many important changes that have been discussed were no longer valid.
Reviewers, don't you worry! The new one is simpler!

This grants the capability to grant privileges over certain restricted indices (.security and .security-6 at the moment). It also removes the special status of the superuser role. IndicesPermission.Group is extended by adding the `allow_restricted_indices` boolean flag. By default the flag is false. When it is toggled, you acknowledge that the indices under the scope of the permission group can cover the restricted indices as well. Otherwise, by default, restricted indices are ignored when granting privileges, thus rendering them hidden for authorization purposes. This effectively adds a confirmation "check-box" for roles that might grant privileges to restricted indices. The "special status" of the superuser role has been removed and coded as any other role: ``` new RoleDescriptor("superuser", new String[] { "all" }, new RoleDescriptor.IndicesPrivileges[] { RoleDescriptor.IndicesPrivileges.builder() .indices("*") .privileges("all") .allowRestrictedIndices(true) // this ----^ .build() }, new RoleDescriptor.ApplicationResourcePrivileges[] { RoleDescriptor.ApplicationResourcePrivileges.builder() .application("*") .privileges("*") .resources("*") .build() }, null, new String[] { "*" }, MetadataUtils.DEFAULT_RESERVED_METADATA, Collections.emptyMap()); ``` In the context of the Backup .security work, this allows the creation of a "curator role" that would permit listing (get settings) for all indices (including the restricted ones). That way the curator role would be able to ist and snapshot all indices, but not read or restore any of them. Supersedes #36765 Relates #34454

albertzaharovits added 7 commits December 18, 2018 10:51

Names

fa07a97

getting there

c12fa0e

HashCode and trimms

59ff695

HasPrivilege

536640d

Husling

4ee6cbd

ReservedRolesStore

ac9ec5a

Merge branch 'master' into strict_privilege_take_3

52e7c2a

albertzaharovits added WIP :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC labels Dec 18, 2018

albertzaharovits self-assigned this Dec 18, 2018

albertzaharovits requested review from tvernum and jaymode December 18, 2018 12:53

albertzaharovits commented Dec 18, 2018

View reviewed changes

albertzaharovits added the >feature label Dec 18, 2018

Trimming

c806970

jaymode requested changes Dec 18, 2018

View reviewed changes

albertzaharovits added 3 commits December 19, 2018 16:24

AuthorizedIndices remove hack + tests

c7f7f2b

More tests and checkstyle

f77fff1

Javadoc and renames

2e92793

albertzaharovits commented Dec 19, 2018

View reviewed changes

two comments

6750306

albertzaharovits commented Dec 19, 2018

View reviewed changes

albertzaharovits added 2 commits December 19, 2018 22:03

import static

b6ea0b3

import static

527a22e

albertzaharovits removed the WIP label Dec 19, 2018

albertzaharovits added 3 commits December 24, 2018 11:38

Merge branch 'backup_security_index' into strict_privilege_take_3

4340bcc

Fix check

2a3f38d

Implicit authorize monitoring passthrough

aadd062

albertzaharovits force-pushed the strict_privilege_take_3 branch from ff1de91 to aadd062 Compare December 25, 2018 11:00

albertzaharovits commented Dec 25, 2018

View reviewed changes

albertzaharovits added 2 commits December 26, 2018 08:59

import static

d63577d

Merge branch 'backup_security_index' into strict_privilege_take_3

7759040

albertzaharovits changed the base branch from backup_security_index to master January 8, 2019 19:32

albertzaharovits added v7.0.0 v6.7.0 labels Jan 8, 2019

jaymode requested changes Jan 8, 2019

View reviewed changes

albertzaharovits added 2 commits January 9, 2019 14:56

Merge branch 'master' into strict_privilege_take_3

eaa4eb2

review nits

ee7e2c2

Compilation minor error

d6191cf

albertzaharovits added 3 commits January 15, 2019 14:21

Merge branch 'master' into strict_privilege_take_3

55aefb6

RoleDescriptor allow_restricted_indices

9f6c739

Mapping

e50ebfc

tvernum reviewed Jan 16, 2019

View reviewed changes

albertzaharovits mentioned this pull request Jan 17, 2019

Permission for restricted indices #37577

Merged

albertzaharovits closed this Jan 17, 2019

colings86 added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019

albertzaharovits deleted the strict_privilege_take_3 branch April 16, 2019 12:51


		public static final IndicesPermission NONE = new IndicesPermission();
		private static final Automaton systemIndicesAutomaton = Automatons.patterns(SystemIndicesNames.indexNames());


		private final ConcurrentMap<String, Predicate<String>> allowedIndicesMatchersForAction = new ConcurrentHashMap<>();
		private final ConcurrentMap<Group, Automaton> indexGroupAutomatonCache = new ConcurrentHashMap<>();

WIldcard IndicesPermissions don't cover .security #36765

WIldcard IndicesPermissions don't cover .security #36765

Conversation

albertzaharovits commented Dec 18, 2018 • edited Loading

elasticmachine commented Dec 18, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaymode left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

albertzaharovits Jan 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

albertzaharovits commented Jan 9, 2019

jaymode commented Jan 11, 2019

albertzaharovits commented Jan 13, 2019

tvernum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

albertzaharovits commented Jan 16, 2019

albertzaharovits commented Jan 17, 2019

albertzaharovits commented Dec 18, 2018 •

edited

Loading

albertzaharovits Jan 9, 2019 •

edited

Loading