jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] ANN: First beta release of Jython-2.0

[<bc...@wo...>]

I am happy to announce the first beta release of Jython 2.0. 

Jython is a Java implementation of the Python programming language.  It
allows users to compile Python source code to Java byte codes, and run
the resulting bytecodes on any Java Virtual Machine. It is a very
seamless and smooth integration with Java: from Python you have complete
access to all Java libraries, can build applets, can integrate with Java
beans, and can subclass Java classes in Python and vice versa. Like
Python, and unlike Java, Jython can also be used interactively: just
type some Jython code at the prompt and see the results immediately.

A java installer is available for download at the Jython website:

    http://jython.sourceforge.net/

Installation is started by running the installer class. Further 
information and tips on installation is available at:

    http://jython.sourceforge.net/install.html

Jython 2.0 is feature compatible with Python 2.0 and among the 
new features are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"

The changes from alpha 3 include:

  New features
    - Installer logo by Ivan Kougaenko. The logo competition is still 
      open, so submit you suggestions.
    - The default packages selected in the installer are now better
      attuned to the users (as opposed to the jython developers).

  Bug fixes.
    - Fixed a NPE when a class is defined in non-module namespace.
    - Fixed a compilation problem when using JDK1.2.x
    - The installer now creates a useable Uninstall.class.

A complete list of changes and differences are available here:

  http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

  http://sourceforge.net/bugs/?group_id=12867

Cheers,
the jython-developers

Re: [Jython-dev] Re: java2 security support: remarks

[<bc...@wo...>]

[Samuele]

>The patch idea is quite nice (I had not thought about such a possibility)
>but unfortunately
>there are some problems.
>First a general remark:
>Our java2 security support should be robust in every situation
>(codesources/protection domains setup),
>even if probably it will be mostly used for applets running within the
>plug-in, or at least we should have a short formulation of what people
>should not do. The actual codebase meets such a requirement: one can allow
>(compiled) jython code to
>use exec at the cost of granting createClassLoader permission, this implies
>that both the code and
>the exec-ed jython fragments must be fully trusted.
>
>In Sun doc it is stated that the use of doPrivileged should be very limited
>and also the amount of code executed inside
>such a privileged context should be limited too. The patch does something
>very different using doPrivileged for every "jython function call" and
>having the privileged region encompass the whole "call".

I think (I'm not sure) that the advice SUN is giving only covers the
doPrivileged method without an explicit AccessControlContext. The
example SUM is supplying is that of a worker thread, and I assume that
the complete work that the worker thread is about to perform should be
executed with a doPrivileged call *with* explicit AccessControlContext.

>a) A bad news about the patch is the perfomance cost of it:
>On my machine with the patch in place the pystones number (using 50000
>iters ) goes down from ~4950 to ~2900.
>I do know very little about how to read pystone results: but this seems to
>me a "big" performance cost that is paid
>globally.
>[In any case I continue to list the "problems" of the patch, maybe there is
>a solution that I do not see, and I think some
>remarks are of more general interest]

I'm sure some optimizing is possible. OTOH, even a high performance hit
is acceptable as long as it is only incurred in very controlled
situations:
- Only when running under a seurity manager, and
- Only if specificly enabled with a property / jythonc option or
- Only when using dynamicly compiled code through exec.

>b) Sun says nothing about using doPrivileged in the context of recursive
>calls: I have no idea if there are problems with that too?
>c) A final version of the patch should clearly avoid that code external to
>jython runtime could exploit the created classloaders,
>   e.g. a method like BytecodeLoader.makeClass should then become package
>protected etc.

Absolutely.

>d) With the patch as it is the (dynamically created) classes-  loaded
>through the BytecodeLoaders - are still put in the protection
> domain of jython runtime: once the access to BytecodeLoader functionality
>is sealed from outside they will/can be just
> the adapters and proxies classes and PyCode-derived classes.
> I don't see a way to exploit the fact that these will be in jython runtime
>prot-dom. But I'm not sure that such a possibilty
> does not exist.

I agree that it is a potential problem, and that I can't rule out the
possibility of an attack either.

>e) Given that our support should work in a general setup:
> - The patch solves the problem of reducing the permissions back to the ones
>of the context of the code that used exec.
>   So if the created code is called from a context with more permissions it
>cannot exploit any of these. That was the issue
>   showed by my example.
>-  On the other hand if the exec-created code is called from a context with
>less permissions, given doPrivileged
>   definition, it will anyway run with the permissions of its creation
>context.

Yes, unfortunate; but I don't think it is a security problem. The high
permission code that made the exec could just run the code itself.
Still, it is bad design to run any code with too high permission.

>   In general java2 security design avoids this kind of situation (but gives
>through doPrivileged a way to obtain this)
>   because then the user during coding should explicitly think about the
>possible security holes that this behaviour opens.
>
>I think that what we need to achieve is the following:
>that exec-created (and the other dynamically created code) should run under
>the intersection of the permissions of the
>creation and execution contexts. One then can use doPrivileged explicitly to
>modify this.
>
>But reading java2 security doc it seems that:
>- There is no way to take 2 AccessControlContext and build a third that
>correspond to the intersection of them.
>- There is no explicit/elegant way to extract the permissions in place given
>a/the current AccessControlContext.
>
>Now I will try to explain an alternative design for a patch. I do not like
>it very much, because it is not very elegant.
>I hope that we can save one the of other approaches or find a derivation of
>this or combination that do the job
>in a reasonable way. This is just a sketch.
>
>Jython runtime should keep a global list PermCands of permissions (e.g. thro
>ugh an HashSet).
>There will be an api to add permissions to the list.
>The init-functions (for proxies, etc.) that now take a classloader should
>then take the proxy/... class too
>and jython should automatically put all the permissions of the prot-dom of
>that class in the list.
>[Cheating at this level will bring no gain]
>
>The actual functionality of BytecodeLoader makeLoader, constructor and
>makeClass/Code methods should be
>completily isolated inside jython runtime: an idea for this is to have
>
>* a SingletonSealedLoader class with just a package protected constructor
>and a method to retrieve the unique class
>that is directly loaded through it:
>the constructor will take the makeClass arguments and an
>AccessControlContext acc.
>* a static package protected function that calls AccessController.getContext
>and then invoke through doPrivileged SingletonSealedLoader ctr with the
>obtained current protection context.
>
>The constructor logic will do the following:
>- if there is no security manager in place just define the class.
>- if there is a security manager in place: define the class inside a
>protection domain,
> the permissions to grant will be computed this way:
>
> Only the permissions from the global set PermsCands for which
>acc.checkPermission do not throw an exception
> will be granted.

Would this create a new ProtectionDomain for each dynamicly loaded
class? What CodeSource would be used for the ProtectionDomain?

>Clearly all this checks have a performance cost, especially when the
>negative result exc is thrown.
>The code can test wheter already AllPermission is ok to gain some speed in
>this case.
>The assumption is that the set will not be that big and in any case the cost
>is local to the dynamic
>creation of code. And zero if there is no security manager in place.

That is good enough. Don't worry about the performance if the hit is
only incurred when actually used.

>So the permissions granted are all actually in place for the code that
>issued the creation request.

Yes, I think this is a safe way to store and later recreate the
permissions of the code that wants to create code dynamicly. And yes,
it's ugly <wink>.

---------------------------------

Only slightly releated: what would happen if an evil applet could
somehow get hold of a PyProxy or PyObject (perhaps through
Applet.getAppletContext().getApplet("foo") ) and then started making
modification to the applet with __setattr__ and __setitem__. The evil
applet cannot introduce new code into the "foo" applet, but if foo it
trusted and is a large application, the evil applet may find enough
usefull methods and functions to build an attack. I haven't tried this
yet, it's just a scary thought.

regards,
finn

[Jython-dev] reloading... : errata

[Samuele P. <pe...@in...>]

Hi. I wrote that too quickly so here are some errata:

Very little thing: clearly a reload support module for java classes cannot
be called reload or we
get a very bad name clash with the reload builtin: something like jreload on
the model of jarray ... will
do the job.

[me writing too quickly]
> I think 1+2 make sense.
Truly I meant "0+1 make sense".

regards, Samuele Pedroni.

[Jython-dev] reloading...

[Samuele P. <pe...@in...>]

Hi.

I'm about to start working on some experimental support for reloading of
java classes.
The interface will be somehow different - as already discussed long time
ago - to that for python modules.
Now the required primitives are in place in the codebase, and the class name
clash bug is fixed.

    For the moment I imagine three levels/ways of support for reload
These are illustrated in the form of some examples of usage (the interface
is clearly not definitive):
0)
    import reload
    reload.createLoadSet("XLS",['d:/exp','d:/exp2'])

    import XLS.com.xyz.utils.BlobReader
    from XLS.com.xyz.utils import Blob

    print XLS.com.xyz.utils.BlobWriter.getVersion()

    reload(XLS)

   # Blob still refers to the old/same version

    print XLS.com.xyz.utils.BlobWriter.getVersion() # refers to new version
    # XLS.com.xyz.utils.BlobReader
1)
    import reload
    xls =
reload.createLoadSet('<anononymous>',['d:/exp','d:/exp2'],topExport=['com.xy
z'])
    # works only if com.xyz is not an existing package under the hierarchy
    # controlled by the system package manager

    print com.xyz.utils.BlobWriter.getVersion() # this works without
prefixing with the load-set

    xls.reload()

   print com.xyz.utils.BlobWriter.getVersion() # new version
2) # same as 1, but should work for packages that are also under control of
the system package manager
    # with that is not meant that we have reloading from classpath or
sys.path
    # but that package content could be splitted between a fixed part coming
from classpath, sys.path
    # and a reloadable one coming from a separated set of directories

Clearly a possibility is to have all them together.
0) I feel is the "more pythonic" being a load set some kind of package that
can be reloaded as a whole.
It also the less confusing for the user.
1) This has the big advantage that the code for the development/test phase
and the final code contain the same imports.
  Can be a bit more confusing.
*)  Clearly the idea is that the reload.createLoadSet are idempotent. To
have the "same" call in many modules
  should report no error... Clearly at least one call should be issued
before trying to import things from
  the load-set.
2) Is more complicated to implement and can be very confusing. I do not know
wheter it's worth the effort.

I think 1+2 make sense.

Comments are welcome.

regards, Samuele Pedroni.

Re: [Jython-dev] Re: java2 security support: remarks

[Samuele P. <pe...@in...>]

Hi. [sorry for the length of this]

[me]
> I will study the patch.
> I see some potential problems but maybe I'm interpreting wrong the java2
> security doc.
The patch idea is quite nice (I had not thought about such a possibility)
but unfortunately
there are some problems.
First a general remark:
Our java2 security support should be robust in every situation
(codesources/protection domains setup),
even if probably it will be mostly used for applets running within the
plug-in, or at least we should have a short formulation of what people
should not do. The actual codebase meets such a requirement: one can allow
(compiled) jython code to
use exec at the cost of granting createClassLoader permission, this implies
that both the code and
the exec-ed jython fragments must be fully trusted.

In Sun doc it is stated that the use of doPrivileged should be very limited
and also the amount of code executed inside
such a privileged context should be limited too. The patch does something
very different using doPrivileged for every "jython function call" and
having the privileged region encompass the whole "call".

a) A bad news about the patch is the perfomance cost of it:
On my machine with the patch in place the pystones number (using 50000
iters ) goes down from ~4950 to ~2900.
I do know very little about how to read pystone results: but this seems to
me a "big" performance cost that is paid
globally.
[In any case I continue to list the "problems" of the patch, maybe there is
a solution that I do not see, and I think some
remarks are of more general interest]
b) Sun says nothing about using doPrivileged in the context of recursive
calls: I have no idea if there are problems with that too?
c) A final version of the patch should clearly avoid that code external to
jython runtime could exploit the created classloaders,
   e.g. a method like BytecodeLoader.makeClass should then become package
protected etc.
d) With the patch as it is the (dynamically created) classes-  loaded
through the BytecodeLoaders - are still put in the protection
 domain of jython runtime: once the access to BytecodeLoader functionality
is sealed from outside they will/can be just
 the adapters and proxies classes and PyCode-derived classes.
 I don't see a way to exploit the fact that these will be in jython runtime
prot-dom. But I'm not sure that such a possibilty
 does not exist.
e) Given that our support should work in a general setup:
 - The patch solves the problem of reducing the permissions back to the ones
of the context of the code that used exec.
   So if the created code is called from a context with more permissions it
cannot exploit any of these. That was the issue
   showed by my example.
-  On the other hand if the exec-created code is called from a context with
less permissions, given doPrivileged
   definition, it will anyway run with the permissions of its creation
context.
   In general java2 security design avoids this kind of situation (but gives
through doPrivileged a way to obtain this)
   because then the user during coding should explicitly think about the
possible security holes that this behaviour opens.

I think that what we need to achieve is the following:
that exec-created (and the other dynamically created code) should run under
the intersection of the permissions of the
creation and execution contexts. One then can use doPrivileged explicitly to
modify this.

But reading java2 security doc it seems that:
- There is no way to take 2 AccessControlContext and build a third that
correspond to the intersection of them.
- There is no explicit/elegant way to extract the permissions in place given
a/the current AccessControlContext.

Now I will try to explain an alternative design for a patch. I do not like
it very much, because it is not very elegant.
I hope that we can save one the of other approaches or find a derivation of
this or combination that do the job
in a reasonable way. This is just a sketch.

Jython runtime should keep a global list PermCands of permissions (e.g. thro
ugh an HashSet).
There will be an api to add permissions to the list.
The init-functions (for proxies, etc.) that now take a classloader should
then take the proxy/... class too
and jython should automatically put all the permissions of the prot-dom of
that class in the list.
[Cheating at this level will bring no gain]

The actual functionality of BytecodeLoader makeLoader, constructor and
makeClass/Code methods should be
completily isolated inside jython runtime: an idea for this is to have

* a SingletonSealedLoader class with just a package protected constructor
and a method to retrieve the unique class
that is directly loaded through it:
the constructor will take the makeClass arguments and an
AccessControlContext acc.
* a static package protected function that calls AccessController.getContext
and then invoke through doPrivileged SingletonSealedLoader ctr with the
obtained current protection context.

The constructor logic will do the following:
- if there is no security manager in place just define the class.
- if there is a security manager in place: define the class inside a
protection domain,
 the permissions to grant will be computed this way:

 Only the permissions from the global set PermsCands for which
acc.checkPermission do not throw an exception
 will be granted.

Clearly all this checks have a performance cost, especially when the
negative result exc is thrown.
The code can test wheter already AllPermission is ok to gain some speed in
this case.
The assumption is that the set will not be that big and in any case the cost
is local to the dynamic
creation of code. And zero if there is no security manager in place.

So the permissions granted are all actually in place for the code that
issued the creation request.

Review of all this is welcome

regards, Samuele Pedroni.

PS:
* Clearly these tentatives of enabling exec for untrusted code will work
only if jython is installed locally and will receive
enough permissions.
* A definitive support for java2 security should probably also do the
following:
both for loading of percompiled ($py.class) jython code and java classes
from sys.path loading the jython runtime
should assign a correct protection domain to the loaded classes through the
SecureClassLoader.defineClass(...,CodeSource csrc) api.

Re: [Jython-dev] Re: java2 security support: remarks

[Samuele P. <pe...@in...>]

Hi.

I will study the patch.
I see some potential problems but maybe I'm interpreting wrong the java2
security doc.

regards, Samuele.

[Jython-dev] [Patch #103025] Use the protection domain of the proxy

[<no...@so...>]

Patch #103025 has been updated. 

Project: jython
Category: None
Status: Open
Submitted by: bckfnn
Assigned to : nobody
Summary: Use the protection domain of the proxy

Follow-Ups:

Date: 2000-Dec-28 06:38
By: bckfnn

Comment:
Updated the patch. Now a AccessControlContext is stored with the PyCode
instance and used when calling the PyCode.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103025&group_id=12867

Re: [Jython-dev] Re: java2 security support: remarks

[<bc...@wo...>]

On Wed, 27 Dec 2000 23:23:15 +0100, you wrote:

>Hi.
>
>Just two things to be pointed out.
>
>[Finn]
>> I'll argue that because the jython runtime needs access to different
>> parts of the filesystem (registry & classes in python.home and
>> directories in the classpath), having the jython runtime around makes
>> the environment less safe.
>>
>> Even when the bug exposed by your example is fixed, adding
>>
>>   grant codeBase "file:${python.home}/-" {
>>     permission java.security.AllPermission "","";
>>   };
>>to a policy file will never be safe. More discretion will always be
>>required.
>
>No that's not the problem, as is it not a problem to give full permissions
>to java runtime
>used to run in the same application trusted and untrusted code.
>The java2 security rules are there to deal with this: at any point the
>intersection of the permissions
>of all code on the stack counts (that means the min common subset). And in
>case of thread
>creation permissions are properly propagated. Up to privileged blocks.
>
>> Regarding the bug, I think a solution is to store the protection domain
>> from the proxy in the system state during Py.initProxy, Py.jgetattr and
>> Py.jfindattr (and in the adapter calls, I think). BytecodeLoader2 will
>> then use this saved protection domain when loading code.
>>
>> [This may open for an attack where the evil applet gets executed on the
>> same thread as a trusted application and thus is able to create code
>> though the BytecodeLoader2 with the protection domain of the trusted
>> application. I'm unsure if it is possible to make the created code
>> execute without the evil applet being on the stack. More analysis is
>> needed]
>>
>> I've uploaded a patch which attempt to save to protection domain in this
>> way. The patch isn't suitable for use because it assume java2 and does
>> not cover the adapters.
>>
>>
>>
>http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103025&grou
>p_id=12867
>>
>This does not solve the bug, which is more a missing feature than a bug.
>This is a possible solution to capture the applet permissions but I should
>repeat this again:
>
>The real point is that in order to allow an applet to use exec we should
>grant to it createClassLoader permission.
>Only if we can avoid this it make sense and it is worth to try to capture
>the permissions of the applet code.
>
>Because if there is a "security hole" around in applicative code, as in my
>example the code that invokes a method of a class instance implementing an
>interface obtained from "untrusted" code.
>Instead of using jython runtime that creates code with the right
>permissions,  the untrusted code can create its own class loader and load
>things with permissions of its choice.
>See:
>http://www.java.sun.com/j2se/1.3/docs/guide/security/permissions.html#Runtim
>ePermission
>
>So for the moment it is simply dangerous to try to allow untrusted code to
>use exec.
>
>So to say AllPermission!=createClassLoader but to grant one of them to
>untrusted code is quite the same: foolish.

Ok. So by putting the "new BytecodeLoader" call in a privileged block we
ensure that only the jython domain needs createClassLoader permission.
The u-dom and t-dom does not.

Then we have to make damn sure that the created code is executed with
the permissions of the initial caller. Otherwise we have created a truck
sized security hole.

I now think the right place to put this restriction is at the PyCode
level, instead of the Class level. For a second, imagine that we have
yet another PyCode implementation which is doing a recusive
interpretation of the parse tree. Such a PyCode implementation should
also be covered by the access restriction of the code base which
compiled the PyCode instance.

In the patch, I now ensure that the execution of a PyTableCode is done
with the AccessControlContext of the code that created the PyTableCode.
The classloader is created in a privileged block, so the
createClassLoader permission no longer require for u-dom and t-dom. 

The assignment of co_context should really be done in a non-public
superclass of PyCode, so that PyCode subclasses can't assign a different
context. I'm sure other things are missing as well.

http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103025&group_id=12867

regards,
finn

[Jython-dev] Re: java2 security support: remarks

[Samuele P. <pe...@in...>]

Hi.

Just two things to be pointed out.

[Finn]
> I'll argue that because the jython runtime needs access to different
> parts of the filesystem (registry & classes in python.home and
> directories in the classpath), having the jython runtime around makes
> the environment less safe.
>
> Even when the bug exposed by your example is fixed, adding
>
>   grant codeBase "file:${python.home}/-" {
>     permission java.security.AllPermission "","";
>   };
>to a policy file will never be safe. More discretion will always be
>required.

No that's not the problem, as is it not a problem to give full permissions
to java runtime
used to run in the same application trusted and untrusted code.
The java2 security rules are there to deal with this: at any point the
intersection of the permissions
of all code on the stack counts (that means the min common subset). And in
case of thread
creation permissions are properly propagated. Up to privileged blocks.

> Regarding the bug, I think a solution is to store the protection domain
> from the proxy in the system state during Py.initProxy, Py.jgetattr and
> Py.jfindattr (and in the adapter calls, I think). BytecodeLoader2 will
> then use this saved protection domain when loading code.
>
> [This may open for an attack where the evil applet gets executed on the
> same thread as a trusted application and thus is able to create code
> though the BytecodeLoader2 with the protection domain of the trusted
> application. I'm unsure if it is possible to make the created code
> execute without the evil applet being on the stack. More analysis is
> needed]
>
> I've uploaded a patch which attempt to save to protection domain in this
> way. The patch isn't suitable for use because it assume java2 and does
> not cover the adapters.
>
>
>
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103025&grou
p_id=12867
>
This does not solve the bug, which is more a missing feature than a bug.
This is a possible solution to capture the applet permissions but I should
repeat this again:

The real point is that in order to allow an applet to use exec we should
grant to it createClassLoader permission.
Only if we can avoid this it make sense and it is worth to try to capture
the permissions of the applet code.

Because if there is a "security hole" around in applicative code, as in my
example the code that invokes a method of a class instance implementing an
interface obtained from "untrusted" code.
Instead of using jython runtime that creates code with the right
permissions,  the untrusted code can create its own class loader and load
things with permissions of its choice.
See:
http://www.java.sun.com/j2se/1.3/docs/guide/security/permissions.html#Runtim
ePermission

So for the moment it is simply dangerous to try to allow untrusted code to
use exec.

So to say AllPermission!=createClassLoader but to grant one of them to
untrusted code is quite the same: foolish.

regards, Samuele.

PS:
>>2) We could provide something like the codebase based logic of the =
>>SecureClassLoader
>>  for jython code loading too.
>
>You think that is possible while maintaining the same API to the "exec"
>statement?
This was a general idea, not related to exec and the "bug".

Re: [Jython-dev] Notes on alpha2 SecureClassLoader/getProtectionDomain patch for BytecodeLoader (things to be aware of plus example)

[<bc...@wo...>]

[Samuele Pedroni]

>I start this with the conclusion (maybe this already clear to everybody =
>but it is better if it is stated somewhere):
>the patch in alpha2 to BytecodeLoader logic that enables to run jython =
>code - that uses
>exec, execfile ... - under java2 plugin, if one gives enough permissions =
>is really only intended to run=20
>fully trusted jython code that uses exec on python fragments fully =
>trusted too.

A good observation.

>On the other side if one gives no permissions, we fall back to the old =
>situation and everything is safe.

This is worth repeating. If no special permission is granted in the
policy file, jython 2.0 applets are as safe as any other applets.

>For anyone knowing java2 security architecture, already the fact that =
>createClassLoader permission
>should be granted to achieve this, should be a sufficient explanation to =
>the conclusion.
>This permission can safely be granted only to really trusted code ...
>
>Having jython runtime around only make it easier to eventually exploit =
>this.

I'll argue that because the jython runtime needs access to different
parts of the filesystem (registry & classes in python.home and
directories in the classpath), having the jython runtime around makes
the environment less safe.

Even when the bug exposed by your example is fixed, adding 

  grant codeBase "file:${python.home}/-" {
    permission java.security.AllPermission "","";
  };

to a policy file will never be safe. More discretion will always be
required. 

Regarding the bug, I think a solution is to store the protection domain
from the proxy in the system state during Py.initProxy, Py.jgetattr and
Py.jfindattr (and in the adapter calls, I think). BytecodeLoader2 will
then use this saved protection domain when loading code. 

[This may open for an attack where the evil applet gets executed on the
same thread as a trusted application and thus is able to create code
though the BytecodeLoader2 with the protection domain of the trusted
application. I'm unsure if it is possible to make the created code
execute without the evil applet being on the stack. More analysis is
needed]

I've uploaded a patch which attempt to save to protection domain in this
way. The patch isn't suitable for use because it assume java2 and does
not cover the adapters.


http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103025&group_id=12867

>PS:
>To improve this (for the future: these are at least not little changes) =
>(just some ideas that possibly work):
>1) We should avoid to be obligated to grant createClassLoader permission =
>to
>  the code that uses exec: maybe this is possible using privileged =
>Blocks.
>  Then it becomes important that the code loaded by the exec
>  receives the same or less permissions than the "code that requested =
>the exec".

It should also cover the dynamically generated proxy classes which is
also loaded by BytecodeLoader2. Even with privileged blocks, the problem
as I see it, is to capture the permission of the originating applet and
use it for the created code. That have to be thread safe, secure and
efficient.

>2) We could provide something like the codebase based logic of the =
>SecureClassLoader
>  for jython code loading too.

You think that is possible while maintaining the same API to the "exec"
statement?


regards,
finn

[Jython-dev] [Patch #103025] Use the protection domain of the proxy

[<no...@so...>]

Patch #103025 has been updated. 

Project: jython
Category: None
Status: Open
Submitted by: bckfnn
Assigned to : nobody
Summary: Use the protection domain of the proxy

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103025&group_id=12867

[Jython-dev] Re: [JPython] Third alpha release of Jython-2.0

[salvatore.didio <sal...@wa...>]

Hello Finn,

Thanks for your work
I don't file any jython class file in the package

Regards

Salvatore




----- Original Message -----
From: Finn Bock <bc...@wo...>
To: <jyt...@li...>
Cc: <jyt...@li...>;
<jyt...@li...>; <jpy...@py...>
Sent: Monday, December 25, 2000 8:11 PM
Subject: [JPython] Third alpha release of Jython-2.0


> Jython-2.0a3 is now available.
>
>   http://jython.sourceforge.net/index.html
>
> Install as with Jython-2.0a2. I don't intend to announce this any
> more widely than these lists for now.
>
> The release includes some bug fixes:
>
>   Bug fixes.
>     - Fixed a bug that caused Infinite recursion in subpackage
>       import
>     - Fixed conversion error when a long is converted to a java double.
>     - Fixed a bug where an attribute in a package __init__.py would
>       hide a submodule.
>     - Fixed missing quotes around the path to java.exe in jython.bat
>       for windows.
>     - Include missing re.py in installer.
>     - Added threading and atexit modules from CPython2.0.
>
>
> Take a look at the NEWS file for more information about the differences.
>
>   http://jython.sourceforge.net/NEWS.html
>
> Bugs can be reported to the bug manager on SourceForge:
>
>   http://sourceforge.net/bugs/?group_id=12867
>
> Cheers,
> the jython-developers
>
> _______________________________________________
> JPython-Interest maillist  -  JPy...@py...
> http://www.python.org/mailman/listinfo/jpython-interest

[Jython-dev] jython logos

[Ivan K. <iv...@ko...>]

2 logos with the same theme... both can be different sizes, transparent
and/or solid backgrounds (these have transparent bckg.)... the smaller one
can be used as a "powered by" logo.
_I

Re: [Jython-dev] Third alpha release of Jython-2.0

[<bc...@wo...>]

[I wrote]

>Jython-2.0a3 is now available. 

and the CVS is tagged and ready for new updates.

I'm aiming for a beta1 release on 31-dec and a beta2 about 2 weeks
later. Hopefully two beta releases will be enough.

regards,
finn

[Jython-dev] Third alpha release of Jython-2.0

[<bc...@wo...>]

Jython-2.0a3 is now available. 

  http://jython.sourceforge.net/index.html

Install as with Jython-2.0a2. I don't intend to announce this any 
more widely than these lists for now.

The release includes some bug fixes:

  Bug fixes.
    - Fixed a bug that caused Infinite recursion in subpackage 
      import
    - Fixed conversion error when a long is converted to a java double.
    - Fixed a bug where an attribute in a package __init__.py would
      hide a submodule.
    - Fixed missing quotes around the path to java.exe in jython.bat 
      for windows.
    - Include missing re.py in installer.
    - Added threading and atexit modules from CPython2.0.


Take a look at the NEWS file for more information about the differences.

  http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

  http://sourceforge.net/bugs/?group_id=12867

Cheers,
the jython-developers

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[<bc...@wo...>]

On Sat, 23 Dec 2000 01:34:41 +0100, you wrote:

>Hi.
>
>[me]
>> Hi
>   [Finn]
>> > Yes. Please commit it. 
>> 
>> I will do that tonight.
>
>done.
>
>PS: commit reporting seems still not to be working.

Right. Atleast we have a python now on the CVS machine now. Still, mails
send to jyt...@li... seems to be lost. I have
added you and me as direct mail address in addition to the
jython-checkins, and I at least get these direct mails. I'm way out of
my depth, but it seems like the host lists.sourceforge.net isn't known
from the CVS machine.

Does anybody have any idea on what the problem could be?

regards,
finn

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[Samuele P. <pe...@in...>]

Hi.

[me]
> Hi
   [Finn]
> > Yes. Please commit it. 
> 
> I will do that tonight.

done.

PS: commit reporting seems still not to be working.

[Jython-dev] kickin'

[Tom L. <TL...@ve...>]

still one of the coolest programming env's ive ever used. thanks guys.
happy holidays!
=20

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[Samuele P. <pe...@in...>]

Hi.
> Yes. Please commit it. 

I will do that tonight.

regards, Samuele.

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[<bc...@wo...>]

[Samuele]

>Finn, thanks for the help and the many examples. Here is a new patch
>proposal.
>The difference is minimal but significative:
>
>         if (ret != null) {
>             // Allow a package component to change its own meaning
>-            PyObject tmp = __dict__.__finditem__(attr);
>-            if (tmp != null)
>-            ret = tmp;
>+            PyObject tmp = modules.__finditem__(fullName);
>+            if (tmp != null) ret = tmp;
>             __dict__.__setitem__(attr, ret);
>             return ret;
>         }
>
>Simply the old jpython code was doing the wrong thing.
>I think this version should be ok for check in. Let me know.

Yes. Please commit it. 

With the patch, it is not longer the jython import mechanism that
prevent pyxml from running with jython.

regards,
finn

Re: [Jython-dev] Can jython / jpython code be called from within JSP pages ?

[Robert W. B. <rb...@di...>]

Hello,

On Thu, 21 Dec 2000, Ray Leyva wrote:
> Just wondering. Cause we're building a site based solely on Java, and
> JSP.  I was wondering if it was possible to use Jython from with JSP,
> and if so can someone send a really really simple ( rudimentary )
> FooBar, World! style sample.
> 
> thx
> rl

I'm been looking at this as well.  So far, I'm unable to use a jythonc
compiled file with Tomcat jsp due to a StackOverflow in __init__ or other 
problems loading the inner class. I think I'm missing something though.

What is sure to work is embedding a PythonInterpreter.  It can go right in
the scriptlet sections, and you can exec python code, or execfile to fill
larger areas of the page from python files.  Here's a brain-dead example
that just uses time from PythonInterpreter in a JSP page to get you
started.  Make sure to add the jython.jar to the classpath and possibly
add -Dpython.home=/path/to/jythondir in the container's startup script.
(This example was tested on Jakarta Tomcat 3.2)

------------begin time.jsp page---------------------------
<%@ page import = "org.python.util.PythonInterpreter" %>
<%@ page import = "org.python.core.*" %>

<html>
<head><title>hello</title></head>
<body bgcolor="white">
<font size=4>

Hello everyone, it is currently 
<% PythonInterpreter interp = new PythonInterpreter();
   interp.exec("from time import ctime, time");
   interp.exec("t = ctime(time())");
   String t = interp.get("t").toString(); %>
<%= t %>
<br>

</font>
</body>
</html>
-------------end time.jsp page----------------------------

You could also write Java files that use PythonInterpreter, and in turn,
use them within the JSP files.  I found myself using PythonInterpreter so
much that I just made a Java class with a runPyFile and runPyCode methods
that respectively set up a JySP directory to run files from,
and exec strings of Jython code.  Both of which just return a String for
the JSP.

It seems likely that jythonc compiled classes should work with JSP- when I
figure out what I'm doing wrong, I'll forward more examples.

Hopefully more to come someday soon :)

-Robert

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[Samuele P. <pe...@in...>]

Hi.

Finn, thanks for the help and the many examples. Here is a new patch
proposal.
The difference is minimal but significative:

         if (ret != null) {
             // Allow a package component to change its own meaning
-            PyObject tmp = __dict__.__finditem__(attr);
-            if (tmp != null)
-            ret = tmp;
+            PyObject tmp = modules.__finditem__(fullName);
+            if (tmp != null) ret = tmp;
             __dict__.__setitem__(attr, ret);
             return ret;
         }

Simply the old jpython code was doing the wrong thing.
I think this version should be ok for check in. Let me know.

Here are the transcripts for the various test-cases with the patch in place:

Jython 2.0alpha2 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from pack1.Node import Node
>>> print Node,type(Node)
pack1.Node.Node org.python.core.PyClass
>>>

Jython 2.0alpha2 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import pack1
>>> print pack1.Node,type(pack1.Node)
pack1.Node org.python.core.PyClass
>>> from pack1.Node import Node
>>> print pack1.Node, type(pack1.Node)
<module pack1.Node at 513138> org.python.core.PyModule

Jython 2.0alpha2 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from pawt import swing
>>> swing
<java package javax.swing at 4653845>
>>> from pawt import swing
>>> swing
<java package javax.swing at 4653845>
>>>

regards, Samuele Pedroni.

[Jython-dev] Can jython / jpython code be called from within JSP pages ?

[Ray L. <Ray...@e-...>]

Just wondering. Cause we're building a site based solely on Java, and
JSP.  I was wondering if it was possible to use Jython from with JSP,
and if so can someone send a really really simple ( rudimentary )
FooBar, World! style sample.

thx
rl

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

[<bc...@wo...>]

[Samuele]

>The issue is clear to me, the cause of this is the following piece of
>code that I left around  as it was:       
>
>
>	if (ret != null) {
>            // Allow a package component to change its own meaning
>            PyObject tmp = __dict__.__finditem__(attr);
>            if (tmp != null)
>            ret = tmp;
>            __dict__.__setitem__(attr, ret);
>            return ret;
>        }
>
>Is that really necessary, I should study a little better CPython semantics.
>Then I will post a fixed fix <wink>.

Make sure that this example still works with your fix. My simple attempt
to solve it (by removing the three "tmp" lines), caused this to fail:

Jython 2.0alpha2 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from pawt import swing
>>> swing
<java package javax.swing at 4504063>
>>> from pawt import swing
>>> swing
<java package javax.swing at 4504063>
>>>

regards,
finn

Re: [Jython-dev] Second alpha release of Jython-2.0

[Mats W. <ma...@la...>]

At 02:26 PM 12/21/2000 +0000, Finn Bock wrote:

 >>
 >>As of b2 the installer is still producing a bad jython.bat
 >>file on Windows systems.  It's not respecting the rule (for
 >>bat files) that all components of the path have to be 8 chars
 >>or less, so if your Java is under "Program Files" that piece
 >>needs to look like "Progra~1".
 >
 >I would rather use quotes (aussming Robert is correct that it works
 >too). The remaining path which isn't fully quoted is the path to the
 >java.exe. Does the script work for you, if you edit jython.bat and adds
 >doublequotes around the path to java.exe?

Yes.  Didn't know that...this way is definitely preferred.