clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hasan Hasan <ha...@trialox.org>
Subject Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent security
Date Wed, 17 Jul 2013 04:11:26 GMT
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 <hasan@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 <reto@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 <hasan@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 <reto@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)
>> >> <jira@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
>> >
>> >
>>
>
>

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