Normally workspaces in Drill DFS plugin should be tied to a directory in the
underlying DFS.
If the user/group that logged in does not have read/write/exec permissions on
the directory, it shouldn’t show up in the show schemas nor should the user be
able to select the workspace in Drill.
Did a quick test and the “enduser” (not part of analyst group and not the
analyst user) was not able to see masterviews workspace tied to directory
views_master in the DFS. The masterviews workspace did not show with show
schemas.
drwxr-x---. 2 analyst analyst 6 Jul 6 20:45 views_master
Plugin info
"masterviews": {
"location": "/data/views_master",
"writable": true,
"defaultInputFormat": null
},
If I try to use it as the “enduser”
use dfs.masterviews;
Error: [MapR][DrillJDBCDriver](500165) Query execution error:
org.apache.drill.common.exceptions.UserRemoteException: VALIDATION ERROR:
Schema [dfs.masterviews] is not valid with respect to either root schema or
current default schema.
Current default schema: No default schema selected
Also if I try to use a view in the directory directly from Drill it reports
back table not found.
Similarly the file permissions will limit access to use the view, but in my
experience the views do show up for user (which causes other issue). However if
the directory permissions are set correctly the workspace does not come up for
the user or group without the correct permissions. I would still recommend to
set view file permissions correctly as well.
In this case I used POSIX file/dir permissions, but some more advanced DFS
systems can handle ACEs, etc which makes it much more workable in large complex
user/schema environments.
See if this solves your issue.
--Andries
On 7/13/17, 5:04 PM, "Paul Rogers" <[email protected]> wrote:
Hi Francis,
I don’t believe that Drill currently has a way to do this: workspaces are
global resources shared across all users. The admin (only) can edit all plugin
and workspace definitions.
We’d need some form of security tags on each definition, and a way to map
users to tags to make this work, but Drill does not yet have this feature.
That said, I believe that, while the workspace itself is public, the files
in the workspace can be restricted using file permissions when you enable
impersonation in Drill. [1]
- Paul
[1] https://drill.apache.org/docs/securing-drill-introduction/
> On Jul 13, 2017, at 1:09 PM, Francis McGregor-Macdonald
<[email protected]> wrote:
>
> Hi,
>
> I have a situation where I would like to restrict access to workspaces
> based on the user. I have an instance where I would like to allow some
> third-party access to a subset of views. I can't find a standard method
> here.
>
> The only similar issue I could find was this:
> https://issues.apache.org/jira/browse/DRILL-3467
>
> Is there a standard practice here to limit workspaces for users?
>
> Thanks,
> Francis
