Try Python update

[Mike Meyer]

Mike, may I ask whether that box has been secured? And if yes how?

If you go to my try_python page and click the "Security" heading,
it'll tell you that the interpreter is run in a chrooted sandbox
inside a FreeBSD jail. You don't have access to anything in the file
system but the code needed to run the interpreter. That's all
write-protected, though I do sometimes forget to write-protect an
upgraded file. I've also removed things from the library that weren't
essential to the application.

Since Python doesn't have any way to secure the interface built-in,
i'd be interrested in that.

Devan apparently doesn't have as cooperative an ISP, and is working on
securing the interpreter. What he's done may be more interesting.

<mike

 

[Devan L]

Xavier Morel <[email protected]> writes:

[Old message and Xavier's question]
[Mike's reply to Xavier]

Devan apparently doesn't have as cooperative an ISP, and is working on
securing the interpreter. What he's done may be more interesting.

It's not particularily interesting. The C code simply has more
attributes restricted in restricted mode, disabling in particular
__subclasses__. The rest is creating safe __builtins__ and only giving
them some modules (but again, importing is still largely broken,
although one liners are still possible).

In any case, I don't know how secure it actually is, since nobody seems
to go further than import os or import sys. So if you're bored, you can
try to break into it. I haven't secured modjelly entirely, and it might
be possible to trick modjelly into executing code by using descriptors
when it tries to pull out all of the information. Then again, I haven't
even added support for properties in it yet. Plus it has no support for
if you delete critical attributes which are needed to recreate the
object. Still, I think it's good enough to deter any random person from
trying to wipe the server for now.

 

[Alex Martelli]

And yes, I know about this. It's listed in "Known Problems". Anything

What's the URL to "Known Problems"? There's a strange cursor-placement
bug on Apple's Safari browser (not in Firefox), but I don't want to add
a bug report if you already know about it -- 'Try Python' is a neat
hack, and useful, it well deserves some care from would-be bug
reporters... but I can't see any links to "known problems" (or other
bug-reporting facilities) from the base page.


Alex

 

[Mike Meyer]

What's the URL to "Known Problems"? There's a strange cursor-placement
bug on Apple's Safari browser (not in Firefox), but I don't want to add
a bug report if you already know about it -- 'Try Python' is a neat
hack, and useful, it well deserves some care from would-be bug
reporters... but I can't see any links to "known problems" (or other
bug-reporting facilities) from the base page.

"Known problems" doesn't have URL (isn't "urlable"?) other than
http://www.mird.org/home/mwm/try_python/. It's on that page - click on
"Known Problems" to open up the section. That particular problem is
listed under "Tested Browsers" (which heading I'm going to change), as
I believe it's a place where the browser fails to follow the standards
- or maybe the standards fail to specify the expected behavior with
sufficient explicitness, as Safari shares this problem with OmmiWeb
and Shiira.

If you can provide the JavaScript fragment to reliably get Safari to
put the cursor after all the text in a textarea, I'll fix this
now.

Thanx,
<mike

 

[Alex Martelli]

"Known problems" doesn't have URL (isn't "urlable"?) other than
http://www.mird.org/home/mwm/try_python/. It's on that page - click on

s/mird/mired/ -- the URL as given goes to some 'oxide' thing.

"Known Problems" to open up the section. That particular problem is

For some reason, I couldn't see the links at the end of the page; now I
can, though they look sort of "ragged", but, OK.

If you can provide the JavaScript fragment to reliably get Safari to
put the cursor after all the text in a textarea, I'll fix this
now.

I'm no Safari expert (and no great shakes at Javascript!), but, I'll ask
around and report back here, thanks.


Alex

 

[Mike Meyer]

For some reason, I couldn't see the links at the end of the page; now I
can, though they look sort of "ragged", but, OK.

Probably the fonts I chose. I'm in no way a good visual designer. I'm
hoping someone who is will step up to help with this.

<mike

 

[Alex Martelli]

Probably the fonts I chose. I'm in no way a good visual designer. I'm
hoping someone who is will step up to help with this.

I'm finding it hard to arrange my own experiments with Safari (I'm using
a loaner machine since my normal one are all having problems and
under repair) but I'm told the solution for cursor positioning is to set
the caretPos attribute of the textarea, like for example at
<http://www.codingforums.com/showthread.php?t=43245> ...


Alex

 

[Mike Meyer]

I'm finding it hard to arrange my own experiments with Safari (I'm using
a loaner machine since my normal one are all having problems and
under repair) but I'm told the solution for cursor positioning is to set
the caretPos attribute of the textarea, like for example at
<http://www.codingforums.com/showthread.php?t=43245> ...

caretPos is apparently an MS extension; it's not supported by Safari
or the Gecko browsers.

setSelectionRange is the standards-compliant version. It's not
supported by Safari either :-(.

Thanks,
<mike

 

[Alex Martelli]

I'm finding it hard to arrange my own experiments with Safari (I'm using
a loaner machine since my normal one are all having problems and
under repair) but I'm told the solution for cursor positioning is to set
the caretPos attribute of the textarea, like for example at
<http://www.codingforums.com/showthread.php?t=43245> ...

caretPos is apparently an MS extension; it's not supported by Safari
or the Gecko browsers.

setSelectionRange is the standards-compliant version. It's not
supported by Safari either :-(.

Meanwhile, other JS/DOM experts have told me that there's NO way to set
cursor position within a textarea according to w3c standards. In this
case, what your site does now may be the "least bad" approach, and that
fact might be noted in the "browsers" subpage, together with a request
for anybody who has other ideas to submit them, I guess.

Sorry for wasting your time, I'm still having trouble believing that the
standards didn't bother to specify SOME way to perform such an
elementary functionality.


Alex

 

[Mike Meyer]

Meanwhile, other JS/DOM experts have told me that there's NO way to set
cursor position within a textarea according to w3c standards. In this
case, what your site does now may be the "least bad" approach, and that
fact might be noted in the "browsers" subpage, together with a request
for anybody who has other ideas to submit them, I guess.

I've done that, and it should show up next time I push the code to the
production server.

Sorry for wasting your time, I'm still having trouble believing that the
standards didn't bother to specify SOME way to perform such an
elementary functionality.

How many pages do you know of that actually want to do this? It may be
fundamental, but it's atypical. I found three different ways to do it
- none of them supported by Safari. Ironically, the browsers that do
support any of those methods all keep the cursor at the end of the
textarea when I add the new text, and so don't need them.

Thanks,
<mike