Hi, During my work on SOLR-11623 "Every request handler in Solr should implement PermissionNameProvider interface" and SOLR-15776 "Make Admin UI play well with Authorization" I got more intimately familiar with how Solr's RBAC permissions are applied (or not applied), and I mapped each Admin screen to what permissions it may require in a spreadsheet: https://docs.google.com/spreadsheets/d/1s2xokDxw9IkXr7ZA5n06RPDj6EwvpbsZ7zUeKpvRC3Q/edit#gid=0 See https://solr.apache.org/guide/8_11/rule-based-authorization-plugin.html#permission-ordering-and-resolution for the RefGuide documentation of permission ordering and resolution.
The system is so different from most other RBAC systems I've seen, and incoming emails and JIRAs suggest that our users often mis-unserstands and mis-configures Solr security. As an example, when I changed the ReplicationHandler so it requires READ permission, some tests started to fail. A user who earlier was granted access due to ALL permission was now denied, since he did not have READ permission. The recent addition of the Security Admin screen makes it easier for users to get it right, as the UI warns you about common mis-conceptions. One typical confusion is that an "edit" permission does not imply the corresponding "read" permission, i.e. if you can have "config-edit" but still not be allowed to read config. And guess what happens if a user is assigned only the "all" permission? Then she is denied "read", "update", "config-edit", "config-read" etc if any of those happen to be configured earlier in the list than the "all" permission. This is due to the first permission in the list matching a certain endpoint is chosen as the "governing permission", and then the user needs to have a role that has exactly that permission configured. I.e. to create a super-user role you need to include every single permission, it is not enough with 'ALL'. While a total re-write based on a standard security library would be nice, that is not in scope for 9.0, so I'll propose some incremental improvements instead, namely that some predefined permissions will imply some others: - Any "FOO-EDIT" permission given to a user will also grant that user the "FOO-READ" permission (not sure that "UPDATE" should imply "READ" though?) - The ALL permission given to a user will also grant that user all other permissions (or otherwise shortcut permission matching with the same effect) - COLLECTION-ADMIN-EDIT/READ will imply CORE-ADMIN-EDIT/READ - Perhaps CONFIG-EDIT should imply SCHEMA-EDIT? Since schema is included in the config-set. Note that even if my proposals here sound smart, I also realize that I may have got it all wrong and that they may totally break other subtle parts of the scheme. I suspect that few of the committers feel they have a total grasp of how current system is intended to work, but don't be afraid to comment anyway. If committers don't understand the system, how can users? :) Jan
