Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] P2 security management
As Henrik said, the repository serialization format is not API. Instead p2 provides various APIs to interact with the repositories (I*Repository) and API to create the IUs themselves (see MetadataFactory class in bundle org.eclipse.equinox.p2.metadata).
That said, don't worry about the repository format changing. Even it was to change we would retain backward compatibility with the existing format to not cause grief to the ecosystem.

On the actual solution, thinking out loud, I'm wondering if you can map the user access rights to p2 categories (a category is just an IU with requirements on the IUs that needs to be shown as part of the category), and to identify which category to show for each right, you could have the category provide specific capabilities. This way, once the application has determined the rights for a given user, the application just has to query the categories for the determined rights and then show the categorized content. With this approach you may be able to have a content.xml that is "static" rather than being generated on every request.

Note that with the generative approach you are taking you want to be careful to the timestamp being returned on the HEAD requests that p2 does to the server to avoid unnecessary downloads. This is because p2 caches content.xml locally based on the timestamp and does HEAD request to know if it is still up-to-date.

HTH

Pascal

On 2013-01-03, at 6:07 AM, Ervin O wrote:

Sorry for the late answer.

This is exactly what I want to do. 

I just want to display custom set of modules(~IUs for simplicity) for the clients based on their access rights. I also need an administration interface where the module developers can publish their modules(module metadata), and the administrators can manage the user's priviliges. The priviliges, users, and metadata for the modules will be stored in a database and I will dinamically generate custom content.xmls for the clients from the database. When the provisioning is initiated, the client downloads this tailored  content.xml, and the invokes the IMetaDataRepositoryManager#loadRepository on the local copy. Currenty I am working on this content.xml generator. The problem is that I think it is not a standardized format for the metadata, but I hope that it won't change in the near future. (I didn't find any schema definition in the content.xml generated by Eclipse) It would be a great improvement in the future to standardize the format of a P2 repository. :)

If you have a better idea then don't hesitate to share it with me.

Thank you,

Ervin

2012/12/18 Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>

When you have something working, it would be great if you could share some of the details of what you’ve done as I’m sure you are not the first one to solve this.

 

Thx

 

Pascal

 

From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Ervin O
Sent: December-17-12 12:31 AM
To: P2 developer discussions
Subject: Re: [p2-dev] P2 security management

 

Thank you for your answer, your idea helped me out.

 

Yes, I will only use Equinox and P2 to achieve my goal.

 

The "downloading the metadata and then invoking P2 on the local copy" is a very good approach. I think, it will solve all of my problems.

 

I will generate custom xml metadata for the users(visibility problem solved), and I will embed a security key into the URL of the artifacts in addition. Then I will check this key on the server, when the client downloads the artifact.

 

It is not problem for example if the user acquires the module in an illlegal way and installs it because these modules are unusable without the server, so hiding the modules is also enough. (Every module of the application is a general purpose thin client.)

 

Best,

 

Ervin

 

2012/12/17 Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx>

Since you say that you are creating an OSGi application I assume this is not for the Eclipse IDE, and that you are planning to use just p2 APi to achieve

what you want. If that is the case, then you can probably just add properties to the IUs in question and then filter those out based on your logic that discriminates on "user x has no right to see y".

 

If you plan to do this with the regular Eclipse p2 UI, then it becomes a matter of configuring the UI - i.e. what it displays in the UI. There are many things that

can be configured, but I am not sure if this is one of them (don't think I heard about this anyway, but I could be wrong). 

 

In any case, this would be a very simple mechanism, clearly the metadata must be accessible by the user, and it needs to be downloaded to the users machine to be operated on - so the user will have this on the local disk and can thus find information and invoke p2 manually to install things (using say the director application, or just snooping, reading the XML text to figure things out). What you can achieve easily is simply a "hide it from the user in the UI". Is that enough?

 

If you want to have real security/license enforcement you would need to do a lot more. License enforcement is best done at runtime rather than install time IMO, but since you want to hide things from users (the mere existence of something installable is an issue), and you may to really keep the information away from the local disk (preventing expert users from figuring things out). If so, then you must either divide things up in different repositories and only giving users the URLs/passwords to those repositories they are allowed to see the content in (password protected, etc). You could also implement your own Repository implementation to do something smarter than downloading all of the metadata, and limit it to what the user is allowed to see.

 

If you have control over the backend repository implementation, you can do things with the URLs/user login, and present the repository layout/content dynamically.

It does not prevent users from using system level tools to mirror things - thus someone may leak sensitive repository content (i.e. mirror/copy things to another repository from which they / or anyone else can install). 

 

Also, once something is installed; it is in re-installable form - someone that can access what is installed can install from this location.

 

Just a couple of ideas (and security concerns to think about) from the top of my mind ... maybe others have better ideas (maybe there are already implementations that does this...) - Yoxos perhaps?

 

If "hiding it in the UI" is enough; the easiest is to do a server backend. If you do this, and you want to write the p2 repository massaging in Java (as opposed to dealing with the XML), you can use the b3 aggregators model of p2 to conveniently load p2 repositories from your (secure) locations, perform the filtering etc. and then output the result as a response to a HTTP request. There are many other options available, but that is what I would do (I have written other p2 repository processing logic that way - unfortunately not available in open source).

 

Hope that helps.

 

Regards

- henrik

 

Henrik Lindberg

 

 

 

On Dec 17, 2012, at 4:56, Ervin O wrote:

 

Hi,

 

I am creating a modular application based on OSGi and I would like to use   P2 for provisioning. 

 

My application will have users who can install modules(deployed as IUs for simplicity) with P2 and I want to restritct the visibility of the modules for the users who have no privilege to install them. 

 

For example, if user U1 has no privilege to install the module M1, then he wouldn't see it in the "available modules" list(retreived from the metadata repository by P2) and can't download it even if he acquired the URL of the IU and the location of the bundle in the artifact repository.

 

Is there any way to do this or I have to do it manually? 

 

In the latter case, my main problem is that I don't know how to tell to P2 to attach the user's session id to the http request (without building a custom P2 that supports this feature).

 

Thanks in advance!

 

Cheers,

 

Ervin

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

 


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

 


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

Back to the top