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

Tue Apr 2 09:36:59 UTC 2013

Dominik,

I was thinking about this.  I think you need to monitor changes to datasets
(org_owner and resources, private) when these change then you can update
the permissions to the resources (db tables)

monitor membership to see which users are in what orgs - and change the
user permissions based on this (maybe it is better to do thiss on the
actual calls to your api - probably much better)

If pg allows roles then this is better so resource has access based on role
(org) and then users get assigned to roles (orgs they are members of)

that seems relatively clean and you don't need to watch resources

sorry for top posting - it was a long weekend

toby

On 28 March 2013 17:00, Dominik Moritz <dominik.moritz at okfn.org> wrote:

>
> 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#L248and 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
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130402/603622b6/attachment.html>