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 <[email protected]> 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 > > > > >
