Settings in Drill that could affect other users.

[John Omernik <jo...@omernik.com>]

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

Re: Settings in Drill that could affect other users.

[John Omernik <jo...@omernik.com>]

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 <jo...@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
>
>
>
>
>