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
