You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org> on 2013/07/12 15:47:48 UTC
[jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent
security
Reto Bachmann-Gmür created CLEREZZA-801:
-------------------------------------------
Summary: Fastlaned Sparql query circumvent security
Key: CLEREZZA-801
URL: https://issues.apache.org/jira/browse/CLEREZZA-801
Project: Clerezza
Issue Type: Bug
Reporter: Reto Bachmann-Gmür
Priority: Critical
No check for access permission on the graph takes place for fastlaned queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Posted by Hasan Hasan <ha...@trialox.org>.
Hi all,
By nextweek I can take some hours to fix some issues (permission check and
handling of default graph).
I'll also list what are pending to implement in the sparql preparser.
Maybe someone can take over the implementation then.
Best regards
Hasan
On Tue, Jul 16, 2013 at 8:04 AM, Hasan Hasan <ha...@trialox.org> wrote:
> Hi Reto
>
> It seems that we have to look into the query to do permission check since
> we can't differentiate from the returned graphs what require read and what
> require readwrite permission.
>
> I'll implement the changes.
>
> By the way, the preparser is not yet finished. Many graphs update or
> management operations are not yet supported
> I can hardly find sometime to finish it before August.
> But let me see what I can do this week.
> I'll let you know this evening
>
> Regards
> Hasan
>
>
>
>
> On Mon, Jul 15, 2013 at 11:32 AM, Reto Bachmann-Gmür <re...@wymiwyg.com>wrote:
>
>> Hi Hasan
>>
>> WIth the slowlane we can do the security checks once the
>> triple-collections are accessed. With fastlane we don't have this
>> possibility as the query is passed to the provider and what happens
>> then is beyond our control.
>>
>> So we need to look at the query.
>>
>> In a simplifying solution:
>> - see that the query is not doing an update operation and accessing
>> graphs A and B in which case we check for read permission on A and B
>>
>> - see that the query is doing an update operation and accessing
>> graphs A and B in which case we check for readwrite permission on A
>> and B
>>
>>
>> In a more advanced solution we would also see that the query
>>
>> COPY <A> TO <B>
>>
>> needs read permisson for A and readwrite permission for B.
>>
>> If the preparser for now would not implement support for the advanced
>> solution this would be no problem. But the API should be already
>> designed in a way to allow support for it. So the preparser should
>> return a tuple of a set of graphs accessed for reading only and one
>> with the graphs accessing for writing too. If for now all update
>> oprations results in all graphs being in the second set, that's no
>> problem.
>>
>> Cheers,
>> Reto
>>
>>
>> On Mon, Jul 15, 2013 at 7:07 AM, Hasan Hasan <ha...@trialox.org> wrote:
>> > Hi Reto,
>> >
>> > I think this should be solved on another layer. The preparser should
>> merely
>> > deal with the query string.
>> > Wouldn't it be better/cleaner that the object that get the referred
>> graphs
>> > from preparser does the check?
>> >
>> > Cheers
>> > Hasan
>> >
>> >
>> > On Sun, Jul 14, 2013 at 5:45 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
>> > wrote:
>> >>
>> >> Hi Hasan
>> >>
>> >> This issue could easily be solved if the preparser could return a set
>> >> of graphs that are accessed reading and a set of graphs that are
>> >> accessed for writing.
>> >>
>> >> WDYT?
>> >>
>> >> Cheers,
>> >> Reto
>> >>
>> >> On Fri, Jul 12, 2013 at 3:47 PM, Reto Bachmann-Gmür (JIRA)
>> >> <ji...@apache.org> wrote:
>> >> > Reto Bachmann-Gmür created CLEREZZA-801:
>> >> > -------------------------------------------
>> >> >
>> >> > Summary: Fastlaned Sparql query circumvent security
>> >> > Key: CLEREZZA-801
>> >> > URL:
>> https://issues.apache.org/jira/browse/CLEREZZA-801
>> >> > Project: Clerezza
>> >> > Issue Type: Bug
>> >> > Reporter: Reto Bachmann-Gmür
>> >> > Priority: Critical
>> >> >
>> >> >
>> >> > No check for access permission on the graph takes place for fastlaned
>> >> > queries.
>> >> >
>> >> > --
>> >> > This message is automatically generated by JIRA.
>> >> > If you think it was sent incorrectly, please contact your JIRA
>> >> > administrators
>> >> > For more information on JIRA, see:
>> >> > http://www.atlassian.com/software/jira
>> >
>> >
>>
>
>
Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Posted by Hasan Hasan <ha...@trialox.org>.
Hi Reto
It seems that we have to look into the query to do permission check since
we can't differentiate from the returned graphs what require read and what
require readwrite permission.
I'll implement the changes.
By the way, the preparser is not yet finished. Many graphs update or
management operations are not yet supported
I can hardly find sometime to finish it before August.
But let me see what I can do this week.
I'll let you know this evening
Regards
Hasan
On Mon, Jul 15, 2013 at 11:32 AM, Reto Bachmann-Gmür <re...@wymiwyg.com>wrote:
> Hi Hasan
>
> WIth the slowlane we can do the security checks once the
> triple-collections are accessed. With fastlane we don't have this
> possibility as the query is passed to the provider and what happens
> then is beyond our control.
>
> So we need to look at the query.
>
> In a simplifying solution:
> - see that the query is not doing an update operation and accessing
> graphs A and B in which case we check for read permission on A and B
>
> - see that the query is doing an update operation and accessing
> graphs A and B in which case we check for readwrite permission on A
> and B
>
>
> In a more advanced solution we would also see that the query
>
> COPY <A> TO <B>
>
> needs read permisson for A and readwrite permission for B.
>
> If the preparser for now would not implement support for the advanced
> solution this would be no problem. But the API should be already
> designed in a way to allow support for it. So the preparser should
> return a tuple of a set of graphs accessed for reading only and one
> with the graphs accessing for writing too. If for now all update
> oprations results in all graphs being in the second set, that's no
> problem.
>
> Cheers,
> Reto
>
>
> On Mon, Jul 15, 2013 at 7:07 AM, Hasan Hasan <ha...@trialox.org> wrote:
> > Hi Reto,
> >
> > I think this should be solved on another layer. The preparser should
> merely
> > deal with the query string.
> > Wouldn't it be better/cleaner that the object that get the referred
> graphs
> > from preparser does the check?
> >
> > Cheers
> > Hasan
> >
> >
> > On Sun, Jul 14, 2013 at 5:45 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
> > wrote:
> >>
> >> Hi Hasan
> >>
> >> This issue could easily be solved if the preparser could return a set
> >> of graphs that are accessed reading and a set of graphs that are
> >> accessed for writing.
> >>
> >> WDYT?
> >>
> >> Cheers,
> >> Reto
> >>
> >> On Fri, Jul 12, 2013 at 3:47 PM, Reto Bachmann-Gmür (JIRA)
> >> <ji...@apache.org> wrote:
> >> > Reto Bachmann-Gmür created CLEREZZA-801:
> >> > -------------------------------------------
> >> >
> >> > Summary: Fastlaned Sparql query circumvent security
> >> > Key: CLEREZZA-801
> >> > URL:
> https://issues.apache.org/jira/browse/CLEREZZA-801
> >> > Project: Clerezza
> >> > Issue Type: Bug
> >> > Reporter: Reto Bachmann-Gmür
> >> > Priority: Critical
> >> >
> >> >
> >> > No check for access permission on the graph takes place for fastlaned
> >> > queries.
> >> >
> >> > --
> >> > This message is automatically generated by JIRA.
> >> > If you think it was sent incorrectly, please contact your JIRA
> >> > administrators
> >> > For more information on JIRA, see:
> >> > http://www.atlassian.com/software/jira
> >
> >
>
Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
Hi Hasan
WIth the slowlane we can do the security checks once the
triple-collections are accessed. With fastlane we don't have this
possibility as the query is passed to the provider and what happens
then is beyond our control.
So we need to look at the query.
In a simplifying solution:
- see that the query is not doing an update operation and accessing
graphs A and B in which case we check for read permission on A and B
- see that the query is doing an update operation and accessing
graphs A and B in which case we check for readwrite permission on A
and B
In a more advanced solution we would also see that the query
COPY <A> TO <B>
needs read permisson for A and readwrite permission for B.
If the preparser for now would not implement support for the advanced
solution this would be no problem. But the API should be already
designed in a way to allow support for it. So the preparser should
return a tuple of a set of graphs accessed for reading only and one
with the graphs accessing for writing too. If for now all update
oprations results in all graphs being in the second set, that's no
problem.
Cheers,
Reto
On Mon, Jul 15, 2013 at 7:07 AM, Hasan Hasan <ha...@trialox.org> wrote:
> Hi Reto,
>
> I think this should be solved on another layer. The preparser should merely
> deal with the query string.
> Wouldn't it be better/cleaner that the object that get the referred graphs
> from preparser does the check?
>
> Cheers
> Hasan
>
>
> On Sun, Jul 14, 2013 at 5:45 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
> wrote:
>>
>> Hi Hasan
>>
>> This issue could easily be solved if the preparser could return a set
>> of graphs that are accessed reading and a set of graphs that are
>> accessed for writing.
>>
>> WDYT?
>>
>> Cheers,
>> Reto
>>
>> On Fri, Jul 12, 2013 at 3:47 PM, Reto Bachmann-Gmür (JIRA)
>> <ji...@apache.org> wrote:
>> > Reto Bachmann-Gmür created CLEREZZA-801:
>> > -------------------------------------------
>> >
>> > Summary: Fastlaned Sparql query circumvent security
>> > Key: CLEREZZA-801
>> > URL: https://issues.apache.org/jira/browse/CLEREZZA-801
>> > Project: Clerezza
>> > Issue Type: Bug
>> > Reporter: Reto Bachmann-Gmür
>> > Priority: Critical
>> >
>> >
>> > No check for access permission on the graph takes place for fastlaned
>> > queries.
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > If you think it was sent incorrectly, please contact your JIRA
>> > administrators
>> > For more information on JIRA, see:
>> > http://www.atlassian.com/software/jira
>
>
Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Posted by Hasan Hasan <ha...@trialox.org>.
Hi Reto,
I think this should be solved on another layer. The preparser should merely
deal with the query string.
Wouldn't it be better/cleaner that the object that get the referred graphs
from preparser does the check?
Cheers
Hasan
On Sun, Jul 14, 2013 at 5:45 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>wrote:
> Hi Hasan
>
> This issue could easily be solved if the preparser could return a set
> of graphs that are accessed reading and a set of graphs that are
> accessed for writing.
>
> WDYT?
>
> Cheers,
> Reto
>
> On Fri, Jul 12, 2013 at 3:47 PM, Reto Bachmann-Gmür (JIRA)
> <ji...@apache.org> wrote:
> > Reto Bachmann-Gmür created CLEREZZA-801:
> > -------------------------------------------
> >
> > Summary: Fastlaned Sparql query circumvent security
> > Key: CLEREZZA-801
> > URL: https://issues.apache.org/jira/browse/CLEREZZA-801
> > Project: Clerezza
> > Issue Type: Bug
> > Reporter: Reto Bachmann-Gmür
> > Priority: Critical
> >
> >
> > No check for access permission on the graph takes place for fastlaned
> queries.
> >
> > --
> > This message is automatically generated by JIRA.
> > If you think it was sent incorrectly, please contact your JIRA
> administrators
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
Hi Hasan
This issue could easily be solved if the preparser could return a set
of graphs that are accessed reading and a set of graphs that are
accessed for writing.
WDYT?
Cheers,
Reto
On Fri, Jul 12, 2013 at 3:47 PM, Reto Bachmann-Gmür (JIRA)
<ji...@apache.org> wrote:
> Reto Bachmann-Gmür created CLEREZZA-801:
> -------------------------------------------
>
> Summary: Fastlaned Sparql query circumvent security
> Key: CLEREZZA-801
> URL: https://issues.apache.org/jira/browse/CLEREZZA-801
> Project: Clerezza
> Issue Type: Bug
> Reporter: Reto Bachmann-Gmür
> Priority: Critical
>
>
> No check for access permission on the graph takes place for fastlaned queries.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira