[Pulp-dev] Package in a different repo does not get added to package list on Module

[Brian Bouterse]

On Wed, Mar 18, 2020 at 9:07 AM Ina Panova <ipanova at redhat.com> wrote:

> This has always been a grey area:
>
> what if the user who has created RepoA cannot access content to the repoB
> and yet we are 'stealing' the content from repoB?
>
This isn't exactly related to your question but I wanted to share a thought.

I call this problem "content isolation", and I hope in the future (maybe
the near-future) Pulp will isolate content per-user/group. Pulp has a
multi-tenancy problem. The reasoning is that pulp is built as a multi-user
system, but as it is your content isn't actually safe from other users.
This could circumvent things like users syncing pay-for redhat content with
pulp and then having other users of that system who are not RH subscribers
have "full access" to that content.

>From a high level, I think the solution to "content isolation problem" is
to use add "user/group" ownership restriction at the queryset level and
probably integrate w/ a user-configurable policy engine like
drf-access-policy
https://rsinger86.github.io/drf-access-policy/multi_tenacy/


> --------
> Regards,
>
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
>
> On Tue, Mar 17, 2020 at 7:41 PM Pavel Picka <ppicka at redhat.com> wrote:
>
>> Hi,
>>
>> started to work on #6295 [0] and by now at sync we look only for actual
>> (repository we are syncing) packages if they are modular and connect to
>> modulemd.
>>
>> To fix this issue we will need to check content from other repositories
>> (already synced) what can have a really huge impact on sync time in case of
>> big repositories.
>>
>> Do we want to get through all pulp content (RPM packages) when syncing
>> new repository with modulemd? Or idea can be to extend sync API call with
>> new argument to scan (all or specific) repositories.
>>
>> I think we would like to keep performance of sync so better to discuss
>> first.
>>
>> Thank you
>>
>> [0] https://pulp.plan.io/issues/6295
>>
>> --
>> Pavel Picka
>> Red Hat
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200323/08435efe/attachment.htm>