The way I'd answer the question is that if you need authorization to be 
enforced by the underlying data store, then the data store must have the 
capability of inbound impersonation. Over time, many storage systems have added 
that function. There was a time in the not too distant past when many 
relational databases didn't support inbound impersonation.

The challenge is that what I'd call "simple file systems" don't usually support 
impersonation. The closest work that I'm aware of was a project by IBM long ago 
on AIX to support identity on a per thread, rather than per process basis and 
the file system honored that.

As Ted pointed out previously with the coarse grained process level security 
model typical of unix file systems, you have to create another process which 
has performance and complexity implications. Not unsolvable of course.

If someone uses a storage system that lacks the needed inbound 
impersonation/identity projection then another solution must be found. As Ted 
points out one option is perimeter security.  Another solution is a product 
that does authorization at a higher level. To a degree Drill views can do this. 
Some other products may have more complex authorization in the higher level 
engine and not rely on the datastore. I'm not a fan of that because it makes 
bypass a little too easy for my taste, but life is full of complex tradeoffs.

Keys
_______________________________
Keys Botzum 
Senior Principal Technologist
kbot...@maprtech.com <mailto:kbot...@maprtech.com>
443-718-0098
MapR Technologies 
http://www.mapr.com <http://www.mapr.com/>
> On Jul 1, 2016, at 3:48 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> 
> On Fri, Jul 1, 2016 at 11:50 AM, Paul Rogers <prog...@maprtech.com> wrote:
> 
>> All of this is a long-winded way of asking this: What do other “big data”
>> tools do to solve this problem? If one is doing big data, should a
>> distributed file system be a requirement if one wants security?
>> 
> 
> Other big data tools use perimeter security. That is a fundamentally
> troubling approach. Good to do, but hardly sufficient.

Reply via email to