[
https://issues.apache.org/jira/browse/DRILL-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381707#comment-17381707
]
ASF GitHub Bot commented on DRILL-7871:
---------------------------------------
paul-rogers commented on pull request #2251:
URL: https://github.com/apache/drill/pull/2251#issuecomment-881151197
Hi @vdiravka,
Thanks for the note, you make good points. Let's see where we can
compromise. Let's start with options.
It makes no sense for users to have their own system options (my favorite
example is the length of the global, shared query queue.) So, `SYSTEM` options
can't be per-user. This means that the `SYSTEM` level has to remain as it is.
We can cut corners: still allow users to change system options, we just ignore
those values. (For example, IIRC, the query queue, the value is taken from the
`SYSTEM` options; we ignore `SESSION` values.) That is, we just trust that user
ignorance will prevent them from breaking things; they won't know about the
system options.
If we have any form of user-property persistence, then we have to worry
about race conditions. I don't see how we can ignore that issue unless we are
strict and we say that user options are read once: when the user starts a
session. If I change `all-text-mode` in session 1, it will not affect session
2. This seems reasonable for the "toy" use cases where Drill is now used.
That is, when a session starts, we set the session options to the saved
per-user values from the persistent store. A nice result is that, at runtime,
there is no difference between user and session options. This fact should save
some work.
The user has to be able to set the user options. We don't need a new option
level. Simply add a new statement: `ALTER USER SET <name>=<value>`. This would
do two things:
1. Write the given key/value pair into the persistent store for the user.
2. Change the session option in the current session to that new value.
Again, we let the user change anything they want; we rely on the fact that
users will only care about one or two options, and only when someone suggests a
change.
The above is simple, but limited. The limits are no worse than today. It
seems we could extend the feature in the future without breaking anything. (For
example, broadcast user option changes to all sessions. Apply security to
system options. Etc.)
Then, we simply ignore the issue that the options users care about are
associated with queries (all the Parquet, JSON, and other options that affect
reader behavior.) We simply decide to be surprised when the user encounters
those issues. User: "Gee, I set the `all-text-mode` option and my queries run
file. But, when Bob runs them, they fail...". Our answer: "have Bob change the
same option" This may break Bob's own queries, so we have Bob change the option
back. This is a horrible user experience, but is the same as what Drill offers
today, so we're not breaking anything.
Will this work?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> StoragePluginStore instances for different users
> ------------------------------------------------
>
> Key: DRILL-7871
> URL: https://issues.apache.org/jira/browse/DRILL-7871
> Project: Apache Drill
> Issue Type: New Feature
> Components: Security
> Affects Versions: 1.18.0
> Reporter: Vitalii Diravka
> Assignee: Vitalii Diravka
> Priority: Major
>
> Different users should have their own storage plugin configs to have access
> to own storages only. The feature can be based on Drill User Impersonation
> model
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
