felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Comprehension question about ProtectionDomain of a Bundle
Date Mon, 29 Sep 2014 11:13:42 GMT
On Mon, Sep 29, 2014 at 12:56 PM, <Dirk.Rudolph@t-systems.com> wrote:

> What happens with Bundle-Location: inputstream:bundle-1.0.0.jar. Is a
> URLHandler available for this?


No.


> So in this case JCE implemtation of OpenJDK will not be supported by
> Apache Felix (OSGI in general?) out of the box?
>

If you choose to give a bundle location that doesn't work than yes, you
have a problem there.

I suppose we could re-work the FakeURLStreamhandler to actually serve up
the content of the revision. So if the OpenJDK JCE implementation would at
least do the right thing with the code source url it might work but I
wouldn't be surprised if they don't (URLs and how to handle them are a mess
in java).

regards,

Karl


> Regards,
> Dirk
>
> -----Ursprüngliche Nachricht-----
> Von: Karl Pauls [mailto:karlpauls@gmail.com]
> Gesendet: Montag, 29. September 2014 12:47
> An: users@felix.apache.org
> Betreff: Re: Comprehension question about ProtectionDomain of a Bundle
>
> In the current Felix setup, though, this URL basically just is an immutable
> > key referring to the abstract Bundle not to the concrete contents of
> > the Bundle. If we expect the CodeSource URL to actually refer to the
> > location from where classes are loaded, then the
> > BundleProtectionDomain should probably take the Content from the
> > BundleRevisionImpl to use as the basis for the CodeSource URL. In this
> > case, though, it is not relevant any longer what the string for the
> bundle location actually is.
> >
>
> The BundleProtectionDomain does the correct thing.
>
> The problem is purely that some library assumes it can get the code source
> of a protection domain and access it. That is wrong and a bad hack at best
> but nothing we can paper over.
> Setting the bundle location as the code source is the correct thing to do.
> If you want to work with that library (or others that do make the same bad
> assumption) you can use a URLHandlers to make it work with your own
> namespace and you are good. This would only be a problem if you would reuse
> bundle locations for bundles that are not identically which you shouldn't
> do in the first place.
>
> regards,
>
> Karl
>
>
> WDYT ?
> >
> > Regards
> > Felix
> >
> > Am 29.09.2014 um 11:27 schrieb <Dirk.Rudolph@t-systems.com> <
> > Dirk.Rudolph@t-systems.com>:
> >
> > > Thanks so far for your explanations.
> > >
> > > So Am I right that each provider that installs bundles in Felix
> > > using a
> > custom bundle location (as Sling OSGI installer does) has to provide a
> > URL handler that is able to resolve to the proper jar file?
> > >
> > > Think about the following cases:
> > >
> > > - Install a bundle using OSGI installer, the Bundle-Location will be
> > jcrinstall:/apps/path/install/bundle-1.0.0.jar for example
> > > - Update the bundle with the same symbolic name but another version
> > using the webconsole, the Bundle-Location will be the same
> > >
> > > or
> > >
> > > - Install a bundle using OSGI installer, the Bundle-Location will be
> > jcrinstall:/apps/path/install/bundle-1.0.0.jar for example
> > > - Update the bundle with the same symbolic name by removing
> > /apps/path/install/bundle-1.0.0.jar  and uploading the new version to
> > /apps/path/install/bundle-1.1.0.jar, the Bundle-Location will also be
> > the same
> > >
> > > Due to this the I think the location of the CodeSource should always
> > point to the cache jar (the one the actual class is loaded from, think
> > about embedded dependency). Otherwise it would be hard to implement a
> > proper URLStreamHandlerService.
> > >
> > > For the JarURLConnection: Is the cached file transient?
> > >
> > > Cheers,
> > > Dirk
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Karl Pauls [mailto:karlpauls@gmail.com]
> > > Gesendet: Montag, 29. September 2014 10:23
> > > An: users@felix.apache.org
> > > Betreff: Re: Comprehension question about ProtectionDomain of a
> > > Bundle
> > >
> > > Hi Dirk,
> > >
> > > we are using bouncycastle as jce provider in our application setup
> > > based
> > on
> > >> AEM (Apache Sling) and I got an error during jar verification.
> > >> (Something with MalformedURLException).
> > >>
> > >
> > > Yeah, irrc they do assume that the code source of a protection
> > > domain is
> > a valid url which isn't necessarily the case for OSGi bundles (I'd
> > argue they shouldn't but oh well).
> > >
> > >
> > >> For my use case I fixed the issue by implementing a
> > >> URLStreamHandlerService providing a URLConnection to the bundle
> > >> location but during my work on this I thought about the topic more
> > >> in
> > general.
> > >>
> > >
> > > I guess that it is probably ok to handle the situation like this
> > assuming you can provide the handler.
> > >
> > >
> > >> As the comment in BundleProtectionDomain.java:38 says the
> > >> CodeSource of a BundleProtectionDomain should be based on the
> > >> revision of the bundle not the bundle itself. (for me the bundle
> > >> location is
> > >> "jcrinstall:/a/path/to/the/bundle.jar")
> > >>
> > >
> > > You should be able to ignore this comment. The
> > > BundleProtectionDomain
> > does indeed provide the bundle revision. It just does get the revision
> > in a stupid way - hence, the comment to remind me that I should figure
> > out a better (i.e., less indirect) way to provide the revision to it.
> > >
> > >
> > >> Is there any reason why the bundle location is used here and not
> > >> the file:///<file:///\\> URL of the revision located in the cache
> instead?
> > >>
> > >
> > > Well, the idea is that you base your security policies on the code
> > source url. That concept would be pretty much meaningless if the code
> > source would be the cached jar. Regardless, the cache implementation
> > (and its layout) is mostly undefined by the spec - the code source is
> > the Bundle-Location URL (consider, for example, the JarURLConnection
> > of the
> > ire: it will cache the jar file on disc as a JarFile but the url will
> > still be the one of the source for the code source).
> > >
> > >
> > >> I mentioned that unfortunatly the JceSecurity implementation has a
> > >> WeakHashMap<Class,URL> that holds the URL to the location of the
> > >> CodeSource. So I assume that it might be possible that the worng
> > >> CodeSource location can be returned there when the cache points to
> > >> a old revision location after a bundle update without garbage
> > >> collection of the old revision. Am I right?
> > >>
> > >
> > > No. The Class object is unique based on its class loader so you will
> > > get
> > the code source URL that was associated with the bundle revision that
> > this class has been loaded from. As long as they key the map by an
> > actual Class object and get the URL from the code source of the
> > BundleProtectionDomain of that class object you should be good.
> > >
> > >
> > > regards,
> > >
> > > Karl
> > >
> > >
> > >> Kind Regards,
> > >>
> > >> Dirk Rudolph
> > >>
> > >>
> > >> T-Systems Multimedia Solutions GmbH Organisationseinheit CCS Dirk
> > >> Rudolph Software-Entwicklung, OCJP
> > >> Hausanschrift: Riesaer Straße 5, 01129 Dresden
> > >> Postanschrift: Postfach 10 02 24, 01072 Dresden
> > >> +49 351 2820-5363       (Tel)
> > >> E-Mail:
> > >> Dirk.Rudolph@t-systems.com<mailto:mDirk.Rudolph@t-systems-mms.com>
> > >> Internet:
> > >> http://www.t-systems-mms.com<http://www.t-systems-mms.de/>
> > >>
> > >> T-Systems Multimedia Solutions GmbH
> > >> Aufsichtsrat: Thilo Kusch (Vorsitzender)
> > >> Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner
> > >> Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft:
> > >> Dresden
> > >> Ust-IdNr.: DE 811 807 949
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> > > http://twitter.com/karlpauls
> > > http://www.linkedin.com/in/karlpauls
> > > https://profiles.google.com/karlpauls
> > >
> > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > CB    [  X  ܚX K  K[XZ[   \ \  ][  X  ܚX P  [ ^  \ X  K ܙ B  ܈ Y  ] [ۘ[
>   [X[
> >    K[XZ[   \ \  Z [    [ ^  \ X  K ܙ B
> >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>



-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message