drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Omernik <j...@omernik.com>
Subject Settings in Drill that could affect other users.
Date Fri, 03 Jun 2016 20:09:36 GMT
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

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 :)


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