[ckan-dev] Get updates for permission changes (related to datastore)

[Dominik Moritz]

On 28 Mar 2013, at 17:06, Toby Dacre <toby.okfn at gmail.com> wrote:

> On 28 March 2013 16:02, Dominik Moritz <dominik.moritz at okfn.org> wrote:
>> 
>> On 28 Mar 2013, at 16:38, Toby Dacre <toby.okfn at gmail.com> wrote:
>> 
>>> On 28 March 2013 12:47, Dominik Moritz <dominik.moritz at okfn.org> wrote:
>>>> Hello everyone,
>>>> 
>>>> There is this issue which I need to solve [1] so that all datasets which are not public are hidden in the datastore as well. Even though we explicitly state the fact in the docs [2] that the SQL search allow access to all datasets, we intend to change this behaviour. The code that will mostly talk about can be found at [3].
>>>> 
>>>> The difficulty with the SQL search is that we have no way of checking which tables are accessed and consequently no way to prevent the query from getting executed or the results to be returned. So my solution would be to prevent access to any datastore table that does not belong to a resource that is part of a public dataset. The way to implement this is to revoke the SELECT privilege for private tables from the read-only pg user that is used by the sql search. In order to do that, I need two things:
>>>> 
>>>> First, a way to get notified if there is a change to the permissions of a resource so that the permissions in the datastore can be adapted. Can IDomainObjectModification be used for that?
>>>> 
>>> 
>>> As I have said previously I think this is a flawed approach.  The
>>> permissions on a resource are to complicated to notify a process on
>>> change without a full database sweep and see my next point which is
>>> more important.
>>> 
>>>> Second, a way to tell whether a resource is part of a private dataset. A crude way to do this is to use a user without any special permissions and then see what `p.toolkit.check_access` returns for `resource_read`.
>>>> 
>>> 
>>> This is the only ckan compliant way to know if a user can read a
>>> resource.  Any other approach means ckan is broken.  I can create an
>>> extension that changes this function and it MUST be respected by all
>>> of ckan.  If not ckan is broken completely.
>> 
>> The thing is that the information about a resource or package alone does not help because we do not know which resources are accessed in a search request. The privileges have to be set before anyone uses the sql search. So I need to solve both problems.
>> 
>>> 
>>>> When we discussed this on IRC, there were some doubts whether this is a good implementation. So I'd like to see whether there are any ideas to hide  resources that are easier, safer or cleaner that the solution I proposed. Also, I don't know how to implement the two things I mentioned above and would like to get suggestions where to look for solutions.
> 
> where is the code that runs the sql?  maybe if I see that it may help with ideas

It starts at https://github.com/okfn/ckan/blob/master/ckanext/datastore/logic/action.py#L248 and goes into https://github.com/okfn/ckan/blob/master/ckanext/datastore/db.py#L1092.

>>>> 
>>>> Best wishes,
>>>> Dominik
>>>> 
>>>> [1] https://github.com/okfn/ckan/issues/652
>>>> [2] http://docs.ckan.org/en/latest/datastore-setup.html
>>>> [3] https://github.com/okfn/ckan/blob/master/ckanext/datastore/logic/action.py
>>>> _______________________________________________
>>>> ckan-dev mailing list
>>>> ckan-dev at lists.okfn.org
>>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>> 
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>> 
>> 
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
> 
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev