drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venki Korukanti <venki.koruka...@gmail.com>
Subject Re: "../" in file pathnames - intend to block or not?
Date Wed, 30 Sep 2015 00:24:59 GMT
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 <adityakishore@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 <dbarclay@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 <dbarclay@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message