Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAOzb7FKjoAEGwwnmXtZSqZSS3auKeQexYMJgrx0H+eFAU8X9EA@mail.gmail.com>
References: <JIRA.12657464.1373636782400@arcas>
	<JIRA.12657464.1373636782400.39761.1373636868578@arcas>
	<CALvhUEX=SymAoOzY1NyZNkv3wFoZrMBpETs70EZfOUfMkDBKjA@mail.gmail.com>
	<CAOzb7FKjoAEGwwnmXtZSqZSS3auKeQexYMJgrx0H+eFAU8X9EA@mail.gmail.com>
Date: Mon, 15 Jul 2013 11:32:34 +0200
Message-ID: 
 <CALvhUEXTatH72nLs7UcxR0kTg8XA3361hvP0irtkj1O385Se6g@mail.gmail.com>
Subject: Re: [jira] [Created] (CLEREZZA-801) Fastlaned Sparql query circumvent
 security
From: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= <reto@wymiwyg.com>
To: Hasan Hasan <hasan@trialox.org>
Cc: dev@clerezza.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 mere=
ly
> deal with the query string.
> Wouldn't it be better/cleaner that the object that get the referred graph=
s
> from preparser does the check?
>
> Cheers
> Hasan
>
>
> On Sun, Jul 14, 2013 at 5:45 PM, Reto Bachmann-Gm=FCr <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=FCr (JIRA)
>> <jira@apache.org> wrote:
>> > Reto Bachmann-Gm=FCr created CLEREZZA-801:
>> > -------------------------------------------
>> >
>> >              Summary: Fastlaned Sparql query circumvent security
>> >                  Key: CLEREZZA-801
>> >                  URL: https://issues.apache.org/jira/browse/CLEREZZA-8=
01
>> >              Project: Clerezza
>> >           Issue Type: Bug
>> >             Reporter: Reto Bachmann-Gm=FCr
>> >             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
>
>