drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Omernik <j...@omernik.com>
Subject Re: Settings in Drill that could affect other users.
Date Mon, 06 Jun 2016 17:56:26 GMT
I'd be interested in discussion on this. Perhaps I am looking at this
incorrectly?

On Fri, Jun 3, 2016 at 3:09 PM, John Omernik <john@omernik.com> wrote:

> As I was thinking about Drill last night, I put on my information security
> hat and realized there may be some settings we need a bit more control
> around.   I haven't tested this yet, I am trying to figure out ways to do
> this, however, my theory was this:
>
>
> There are some variables that could maliciously or accidently be set in
> such a way as to have a negative effect on the cluster...
>
> Say an alter session on : planner.memory.max_query_memory_per_node
>
> As a user, without admin privs, I could set this to be what I wanted...
>
> So then I thought what about the security.admin.users?  I tried this and
> got an error (thankfully!)
>
> Error: VALIDATION ERROR: Admin related settings can only be set at SYSTEM
> level scope. Given scope 'SESSION'.
>
> So,  good, however, I could very easily set my
> planner.memory.max_query_memory_per_node to a higher amount (I set it to
> 20GB instead of 2GB) That's scary to think about... consider the
> (non-malicious) use case where a user is running a query on a shared
> cluster, and they get an error, and decide to google this list, where
> people recommend changing it, so they do, they increase it greatly. The
> affect of the users session level change, could be detrimental to other
> users.
>
> There are a number of variables like this, where I could see them causing
> system level issues even within a session.
>
> So some thoughts:
>
> 1. Making more variables "Admin related" so they can only be changed  This
> is a option to have a throughful discussion on the variables could be used
> and misused, and lock some settings down to admin only.
>
> 2. For some variables, have defaults, still allow users to change, but
> then have other, admin only variables that set say a min/max value for the
> setting.  So on the planner.memory.max_query_memory_per_node, perhaps I
> will leave it as a default setting of 2GB, but I am ok if the user sets it
> in session up to 10GB. This is much more complex to think about, but
> provides some neat flexibility.
>
> 3. Perhaps there should be permissions on variables.   Some variables are
> not allowed to even be seen if not in the admin group. (select * from
> sys.options wouldn't even show them).  I am not sure that would be a great
> thing, in that it make user troubleshooting harder, but in line with my
> other post about Adding descriptions to variables, outlining which
> variables CAN be changed by the user through another column may not be a
> bad idea.
>
>
> There is a lot more to discuss here, but all in all, the security around
> options, as well as workspaces really needs some TLC for Drill be stronger
> in the enterprise.   Thinking how people could inadvertently affect others
> would be a good exercise in these cases, and then when we have that
> resolved, we can look at the ways people could maliciously affect others :)
>
> John
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message