"../" in file pathnames - intend to block or not?

[Daniel Barclay <db...@maprtech.com>]

In file/directory pathnames for tables, does Drill intend to block use of "../" that traverses up beyond the root of the workspace (i.e., above /tmp for (default) dfs.tmp)?

Daniel

-- 
Daniel Barclay
MapR Technologies

Re: "../" in file pathnames - intend to block or not?

[Venki Korukanti <ve...@gmail.com>]

With or without impersonation enabled if the user doesn't have access to
the resolved final path, it should throw permission error, because we rely
FileSystem for access control. However we could make an improvement to exit
much early in validation itself if we see a path that is not resolved to a
path under the workspace.

On Tue, Sep 29, 2015 at 5:11 PM, Aditya <ad...@gmail.com> wrote:

> If the user is able to access data outside of the root of the workspace, I
> would consider that as a security vulnerability.
>
> On Tue, Sep 29, 2015 at 4:51 PM, Daniel Barclay <db...@maprtech.com>
> wrote:
>
> > Jason Altekruse wrote:
> >
> >> Yes, we want workspaces to be able to used in conjunction with
> >> authentication to provide limited views of data to some users. Is this
> >> currently not being enforced?
> >>
> >
> > I'm not sure what would be enforced with authentication/impersonation
> > turned on (especially, whether access is checked after all pathname
> > resolution is done or is checked too early).
> >
> > I was just running in regular (no-impersonation) local mode and noticed
> > that using "../" in a pathname can get to directories outside the
> > workspace's root.
> >
> > Is that behavior expected or is that a bug?
> >
> > (Part of, or another way to ask, my question is whether we:
> > - only intend the workspace to be a like a default working directory
> >   (where you usually give downward-only relative names to files in its
> >   subtree, but might occasionally reach out of the subtree), or
> > - intend the workspace to be more restricted.)
> >
> >
> > Daniel
> >
> >
> >
> >
> >> On Tue, Sep 29, 2015 at 3:49 PM, Daniel Barclay <db...@maprtech.com>
> >> wrote:
> >>
> >> In file/directory pathnames for tables, does Drill intend to block use
> of
> >>> "../" that traverses up beyond the root of the workspace (i.e., above
> >>> /tmp
> >>> for (default) dfs.tmp)?
> >>>
> >>> Daniel
> >>>
> >>> --
> >>> Daniel Barclay
> >>> MapR Technologies
> >>>
> >>>
> >>>
> >>
> >
> > --
> > Daniel Barclay
> > MapR Technologies
> >
>

Re: "../" in file pathnames - intend to block or not?

[Aditya <ad...@gmail.com>]

If the user is able to access data outside of the root of the workspace, I
would consider that as a security vulnerability.

On Tue, Sep 29, 2015 at 4:51 PM, Daniel Barclay <db...@maprtech.com>
wrote:

> Jason Altekruse wrote:
>
>> Yes, we want workspaces to be able to used in conjunction with
>> authentication to provide limited views of data to some users. Is this
>> currently not being enforced?
>>
>
> I'm not sure what would be enforced with authentication/impersonation
> turned on (especially, whether access is checked after all pathname
> resolution is done or is checked too early).
>
> I was just running in regular (no-impersonation) local mode and noticed
> that using "../" in a pathname can get to directories outside the
> workspace's root.
>
> Is that behavior expected or is that a bug?
>
> (Part of, or another way to ask, my question is whether we:
> - only intend the workspace to be a like a default working directory
>   (where you usually give downward-only relative names to files in its
>   subtree, but might occasionally reach out of the subtree), or
> - intend the workspace to be more restricted.)
>
>
> Daniel
>
>
>
>
>> On Tue, Sep 29, 2015 at 3:49 PM, Daniel Barclay <db...@maprtech.com>
>> wrote:
>>
>> In file/directory pathnames for tables, does Drill intend to block use of
>>> "../" that traverses up beyond the root of the workspace (i.e., above
>>> /tmp
>>> for (default) dfs.tmp)?
>>>
>>> Daniel
>>>
>>> --
>>> Daniel Barclay
>>> MapR Technologies
>>>
>>>
>>>
>>
>
> --
> Daniel Barclay
> MapR Technologies
>

Re: "../" in file pathnames - intend to block or not?

[Daniel Barclay <db...@maprtech.com>]

Jason Altekruse wrote:
> Yes, we want workspaces to be able to used in conjunction with
> authentication to provide limited views of data to some users. Is this
> currently not being enforced?

I'm not sure what would be enforced with authentication/impersonation
turned on (especially, whether access is checked after all pathname
resolution is done or is checked too early).

I was just running in regular (no-impersonation) local mode and noticed
that using "../" in a pathname can get to directories outside the
workspace's root.

Is that behavior expected or is that a bug?

(Part of, or another way to ask, my question is whether we:
- only intend the workspace to be a like a default working directory
   (where you usually give downward-only relative names to files in its
   subtree, but might occasionally reach out of the subtree), or
- intend the workspace to be more restricted.)


Daniel


>
> On Tue, Sep 29, 2015 at 3:49 PM, Daniel Barclay <db...@maprtech.com>
> wrote:
>
>> In file/directory pathnames for tables, does Drill intend to block use of
>> "../" that traverses up beyond the root of the workspace (i.e., above /tmp
>> for (default) dfs.tmp)?
>>
>> Daniel
>>
>> --
>> Daniel Barclay
>> MapR Technologies
>>
>>
>


-- 
Daniel Barclay
MapR Technologies

Re: "../" in file pathnames - intend to block or not?

[Jason Altekruse <al...@gmail.com>]

Yes, we want workspaces to be able to used in conjunction with
authentication to provide limited views of data to some users. Is this
currently not being enforced?

On Tue, Sep 29, 2015 at 3:49 PM, Daniel Barclay <db...@maprtech.com>
wrote:

> In file/directory pathnames for tables, does Drill intend to block use of
> "../" that traverses up beyond the root of the workspace (i.e., above /tmp
> for (default) dfs.tmp)?
>
> Daniel
>
> --
> Daniel Barclay
> MapR Technologies
>
>