Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91220 > unrolled thread

Creating a reliable sandboxed Python environment

Back to article view | Back to comp.lang.python

Contents

  Creating a reliable sandboxed Python environment davidfstr@gmail.com - 2015-05-25 19:24 -0700
    Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-26 12:44 +1000
    Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-25 23:17 -0700
    Re: Creating a reliable sandboxed Python environment Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-26 17:10 +1000
      Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-26 09:53 +0200
      Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-26 10:02 +0200
    Re: Creating a reliable sandboxed Python environment Ned Batchelder <ned@nedbatchelder.com> - 2015-05-26 03:21 -0700
    Re: Creating a reliable sandboxed Python environment marco.nawijn@colosso.nl - 2015-05-26 05:01 -0700
    Re: Creating a reliable sandboxed Python environment davidfstr@gmail.com - 2015-05-28 09:34 -0700
      Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-30 20:13 -0700
    Re: Creating a reliable sandboxed Python environment Stefan Behnel <stefan_ml@behnel.de> - 2015-05-28 20:41 +0200
    Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-29 04:51 +1000
      Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-29 11:30 -0700
        Re: Creating a reliable sandboxed Python environment Marko Rauhamaa <marko@pacujo.net> - 2015-05-29 22:12 +0300
          Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-29 13:15 -0700
    Re: Creating a reliable sandboxed Python environment Stefan Behnel <stefan_ml@behnel.de> - 2015-05-29 08:18 +0200
    Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-29 17:41 +1000
      Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-29 11:33 -0700
        Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-30 08:49 +1000
          Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-29 18:28 -0700
            Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-30 12:42 +1000
              Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-29 21:48 -0700
                Re: Creating a reliable sandboxed Python environment Steven D'Aprano <steve@pearwood.info> - 2015-05-30 19:00 +1000
                  Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-30 13:24 +0200
                    Re: Creating a reliable sandboxed Python environment Steven D'Aprano <steve@pearwood.info> - 2015-05-31 09:52 +1000
                      Re: Creating a reliable sandboxed Python environment Modulok <modulok@gmail.com> - 2015-05-30 19:08 -0600
                      Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-31 08:14 +0200
                  Re: Creating a reliable sandboxed Python environment Stefan Behnel <stefan_ml@behnel.de> - 2015-05-30 20:42 +0200
                  Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-30 13:00 -0700
                    Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-31 08:20 +1000
                      Re: Creating a reliable sandboxed Python environment Paul Rubin <no.email@nospam.invalid> - 2015-05-30 15:36 -0700
                  Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-30 22:54 +0200
          Re: Creating a reliable sandboxed Python environment BartC <bc@freeuk.com> - 2015-05-30 13:06 +0100
            Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-30 22:37 +1000
    Re: Creating a reliable sandboxed Python environment Stefan Behnel <stefan_ml@behnel.de> - 2015-05-29 11:23 +0200
    Re: Creating a reliable sandboxed Python environment Chris Angelico <rosuav@gmail.com> - 2015-05-29 19:38 +1000
    Re: Creating a reliable sandboxed Python environment Laura Creighton <lac@openend.se> - 2015-05-29 11:56 +0200

Page 2 of 2 — ← Prev page 1 [2]

#91512

On Sat, May 30, 2015 at 11:28 AM, Paul Rubin <no.email@nospam.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Do you see what I mean about functionality being sacrificed for
>> security?
>
> No I don't.  Lua has less functionality because it was designed to have
> a small embedding footprint.  Python is much bigger because it was
> mostly designed to run as a standalone interpreter.  That has nothing to
> do with security.  You haven't shown the slightest connection between
> Lua's lower functionality and its higher sandbox security, because there
> is none.  The lower functionality is because of a totally independent
> reason, namely the desire to make the interpreter smaller.

This thread started out as "How can I sandbox Python inside Python?".
One of the responses was "You can't, but try sandboxing Lua inside
Python instead". This has the cost that Lua, unlike Python, simply
lacks features. You can *easily* sandbox something that has very
little functionality - all you have to do is provide a minimalist
"language" that permits only a very few actions, and you know it's
safe. But that security comes at a price.

ChrisA

[toc] | [prev] | [next] | [standalone]

#91513

Chris Angelico <rosuav@gmail.com> writes:
> You can *easily* sandbox something that has very little functionality
> - all you have to do is provide a minimalist "language" that permits
> only a very few actions, and you know it's safe. But that security
> comes at a price.

This is a non-sequitur.  The reason they didn't put more features into
Lua is that it would have made the memory footprint bigger and they
pitch it as an embeddable extension engine so they want to keep it
small.  Stuff like bignums and unicode in themselves wouldn't have
affected security.  There's no obstacle to implementing Python the way
Lua is implemented, and for all I know, MicroPython does that.  It just
didn't happen to be done that way with CPython because of Python's
expected mode of use historically.  Armin Ronacher's blog entry that I
linked says a little more about this.

Heck, think of Java, which is monstrously more complicated than Python
and supports applet sandboxing, plus it can run Python programs (under
Jython).  Or Javascript, which has similar complexity to Python and runs
sandboxes in millions (billions?) of browsers.

[toc] | [prev] | [next] | [standalone]

#91519

On Sat, 30 May 2015 02:48 pm, Paul Rubin wrote:

> Chris Angelico <rosuav@gmail.com> writes:
>> You can *easily* sandbox something that has very little functionality
>> - all you have to do is provide a minimalist "language" that permits
>> only a very few actions, and you know it's safe. But that security
>> comes at a price.
> 
> This is a non-sequitur. The reason they didn't put more features into 
> Lua is that it would have made the memory footprint bigger and they
> pitch it as an embeddable extension engine so they want to keep it
> small.  

I wouldn't have imagined that the claim "it's easier to secure a small
language with a few features than a big language with lots of features"
would have been so controversial. I wonder if this claim will be equally as
controversial?

There is a rough correlation between the number of lines of code in a code
base, and the number of potential security holes that need to be guarded
against.


> Stuff like bignums and unicode in themselves wouldn't have 
> affected security. 

Do you consider a Denial of Service or Memory Exhaustion attack to be a
security issue? If not, try running this in Python:

100**100**100

(Perhaps not a great idea.) How about defeating cryptographic protection
mechanisms?

https://www.auscert.org.au/21885

Or using Unicode to bypass data validation?

https://capec.mitre.org/data/definitions/71.html

Unicode encoding attacks?

https://www.owasp.org/index.php/Unicode_Encoding
https://cwe.mitre.org/data/definitions/176.html

Unicode spoofing? Buffer overflows? UTF-8 exploits? IDNA exploits? Code
point deletion exploits? Malicious rendering?

http://unicode.org/reports/tr36/
http://unicode.org/faq/security.html


[...]
> Heck, think of Java, which is monstrously more complicated than Python
> and supports applet sandboxing, plus it can run Python programs (under
> Jython).  Or Javascript, which has similar complexity to Python and runs
> sandboxes in millions (billions?) of browsers.

Funny you should mention Javascript...

http://securityevaluators.com/knowledge/papers/engineeringheapoverflow.pdf
http://security.stackexchange.com/questions/41966/
https://nakedsecurity.sophos.com/exploring-the-blackhole-exploit-kit-7/
http://resources.infosecinstitute.com/fbi-tor-exploit/
https://www.mozilla.org/en-US/security/advisories/mfsa2013-53/

Yes, I can see why you think Javascript is securely sandboxed...

*wink*



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#91526

In a message of Sat, 30 May 2015 19:00:14 +1000, "Steven D'Aprano" writes:
>I wouldn't have imagined that the claim "it's easier to secure a small
>language with a few features than a big language with lots of features"
>would have been so controversial. I wonder if this claim will be equally as
>controversial?
>
>There is a rough correlation between the number of lines of code in a code
>base, and the number of potential security holes that need to be guarded
>against.

Maybe these aren't controversial if you are doing langauge level
sandboxing, but you don't have to sandbox like that.  Consider, for a
moment, the sandboxing technique used by PyPy
discussed at

http://pypy.readthedocs.org/en/latest/sandbox.html

You think it is way cool, but, alas, you want to sandbox some other
language than Python.

What do you do?  You write an interpreter for this language in
RPython.  Clearly, writing such a thing will be a lot easier for 'the
toy language that does hardly anything I invented this morning' as
opposed to 'javascript that is expected to operate in the real world'
but this has nothing to do with the security aspects of the two
langauges.  You'd have the exact same problem of difficulty even if
you never intend to sandbox the thing at all.   The sandboxing
aspects will happen, automatically, as soon as you have a
written a working interpreter.  The layer that provides the security
doesn't care about your target language, just as long as it is written in
RPython.

As a point of fact, We've _already got_ Topaz, a Ruby interpreter,
Hippy, a PHP interpreter, a Prolog interpreter, a Smalltalk
interpeter, and a javascript interpreter.  Recently we got Pyket a
Racket compiler.  There also exist plenty of experimental languages
written by academic langauge designers, and other crazy people who
like such things.  But don't ask the PyPy project about hard is it to
sandbox one versus the other.  From our point of view, they all cost
the same -- free, as in _already done for you_, same as you get a JIT
for free, and pluggable garbage collectors for free, etc. etc.

If you find this stuff interesting, come check it out.

Laura

[toc] | [prev] | [next] | [standalone]

#91554

On Sat, 30 May 2015 09:24 pm, Laura Creighton wrote:

> In a message of Sat, 30 May 2015 19:00:14 +1000, "Steven D'Aprano" writes:
>>I wouldn't have imagined that the claim "it's easier to secure a small
>>language with a few features than a big language with lots of features"
>>would have been so controversial. I wonder if this claim will be equally
>>as controversial?
>>
>>There is a rough correlation between the number of lines of code in a code
>>base, and the number of potential security holes that need to be guarded
>>against.
> 
> Maybe these aren't controversial if you are doing langauge level
> sandboxing, but you don't have to sandbox like that.  Consider, for a
> moment, the sandboxing technique used by PyPy
> discussed at
> 
> http://pypy.readthedocs.org/en/latest/sandbox.html
> 
> You think it is way cool, but, alas, you want to sandbox some other
> language than Python.

How many PyPy sandboxes are being used with hostile users motivated to break
out of the sandbox?

"I wrote a sandbox which I can't break out of" is different from "I wrote a
sandbox which nobody can break out of". Javascript is sandboxed, but due to
bugs in implementations, Javascript-based exploits are now heavily used by
malware. There are possibly even more Javascript-based exploits than buffer
overflow based exploits these days, as C programmers get better at using
automated tools that check for buffer overflows.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#91555

[Multipart message — attachments visible in raw view] — view raw

While this thread is indeed a theoretical discussion of the interpreter,
for a practical solution where you control the host environment, one might
look into OS level sandboxing like FreeBSD's Jails (not to be confused with
a simple chroot environment) along with various resource limiting
parameters. You can lock down a 'sandboxed' i.e. jailed environment for
arbitrary data and processes, including python, pretty tightly.

-Kurt-

On Sat, May 30, 2015 at 5:52 PM, Steven D'Aprano <steve@pearwood.info>
wrote:

> On Sat, 30 May 2015 09:24 pm, Laura Creighton wrote:
>
> > In a message of Sat, 30 May 2015 19:00:14 +1000, "Steven D'Aprano"
> writes:
> >>I wouldn't have imagined that the claim "it's easier to secure a small
> >>language with a few features than a big language with lots of features"
> >>would have been so controversial. I wonder if this claim will be equally
> >>as controversial?
> >>
> >>There is a rough correlation between the number of lines of code in a
> code
> >>base, and the number of potential security holes that need to be guarded
> >>against.
> >
> > Maybe these aren't controversial if you are doing langauge level
> > sandboxing, but you don't have to sandbox like that.  Consider, for a
> > moment, the sandboxing technique used by PyPy
> > discussed at
> >
> > http://pypy.readthedocs.org/en/latest/sandbox.html
> >
> > You think it is way cool, but, alas, you want to sandbox some other
> > language than Python.
>
> How many PyPy sandboxes are being used with hostile users motivated to
> break
> out of the sandbox?
>
> "I wrote a sandbox which I can't break out of" is different from "I wrote a
> sandbox which nobody can break out of". Javascript is sandboxed, but due to
> bugs in implementations, Javascript-based exploits are now heavily used by
> malware. There are possibly even more Javascript-based exploits than buffer
> overflow based exploits these days, as C programmers get better at using
> automated tools that check for buffer overflows.
>
>
>
> --
> Steven
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#91566

In a message of Sun, 31 May 2015 09:52:29 +1000, "Steven D'Aprano" writes:
>How many PyPy sandboxes are being used with hostile users motivated to break
>out of the sandbox?
>
>"I wrote a sandbox which I can't break out of" is different from "I wrote a
>sandbox which nobody can break out of". Javascript is sandboxed, but due to
>bugs in implementations, Javascript-based exploits are now heavily used by
>malware. There are possibly even more Javascript-based exploits than buffer
>overflow based exploits these days, as C programmers get better at using
>automated tools that check for buffer overflows.

I don't know, as we don't really have a way of tracking who is using
PyPy for anything.  We know we have some.

Laura

[toc] | [prev] | [next] | [standalone]

#91537

Laura Creighton schrieb am 30.05.2015 um 13:24:
> As a point of fact, We've _already got_ Topaz, a Ruby interpreter,
> Hippy, a PHP interpreter, a Prolog interpreter, a Smalltalk
> interpeter, and a javascript interpreter.  Recently we got Pyket a
> Racket compiler.  There also exist plenty of experimental languages
> written by academic langauge designers, and other crazy people who
> like such things.  But don't ask the PyPy project about hard is it to
> sandbox one versus the other.  From our point of view, they all cost
> the same -- free, as in _already done for you_, same as you get a JIT
> for free, and pluggable garbage collectors for free, etc. etc.

So here the cost of security is actually rewriting the entire language
runtime and potentially also major parts of its ecosystem? Not exactly a
cheap price either.

Stefan

[toc] | [prev] | [next] | [standalone]

#91541

Steven D'Aprano <steve@pearwood.info> writes:
> I wouldn't have imagined that the claim "it's easier to secure a small
> language with a few features than a big language with lots of features"
> would have been so controversial.

Consider that if the small language is Turing-complete, you can use it
to implement the big language.  If the small language is also secure (in
the sense of not being able to escape a sandbox), the big language
implemented in it can't escape the sandbox either.  Therefore the size
of the language doesn't inherently affect the sandbox security.

Implementing Python in Lua (with LuaJIT) might even have tolerable
performance, possibly beating CPython.

> I wonder if this claim will be equally as controversial?  There is a
> rough correlation between the number of lines of code in a code base,
> and the number of potential security holes that need to be guarded
> against.

Bigger programs are more likely to have bugs, sure, and Lua might have
those already.  But that's not the issue Python faces regarding
sandboxing, where it's insecure by design.

>> Stuff like bignums and unicode in themselves wouldn't have 
>> affected security. 
>
> Do you consider a Denial of Service or Memory Exhaustion attack to be a
> security issue? 

It's less of an issue on the client side were you don't mind too much if
an attacker DOS's his own machine.  Otherwise you have to consider
memory allocation and CPU cycles to be controlled system resources,
which is not rocket science (every operating system does that).  I'm not
sure where Lua sits with regard to this.

> If not, try running this in Python:
> 100**100**100

That's not an issue with bignums in themselves, but rather it's an
artifact of CPython's implementation.  Exponentiation works by repeated
squaring, and each squaring step only doubles the size of its input and
uses predictable cycles, so a sandboxed implementation could get by with
just checking input sizes before every multiplication.

> (Perhaps not a great idea.) How about defeating cryptographic protection
> mechanisms?...
> Or using Unicode to bypass data validation?...
> https://capec.mitre.org/data/definitions/71.html
> Unicode encoding attacks?... ... ...

None of the stuff you listed appear to be issues inherent with
supporting some feature in a language.  They are mostly application and
library bugs.  I got bored enough that I didn't look at all of them, so
maybe I missed something.

[toc] | [prev] | [next] | [standalone]

#91545

On Sun, May 31, 2015 at 6:00 AM, Paul Rubin <no.email@nospam.invalid> wrote:
> Steven D'Aprano <steve@pearwood.info> writes:
>> I wouldn't have imagined that the claim "it's easier to secure a small
>> language with a few features than a big language with lots of features"
>> would have been so controversial.
>
> Consider that if the small language is Turing-complete, you can use it
> to implement the big language.  If the small language is also secure (in
> the sense of not being able to escape a sandbox), the big language
> implemented in it can't escape the sandbox either.  Therefore the size
> of the language doesn't inherently affect the sandbox security.

Turing completeness isn't the whole story. How do you go about
sandboxing a Brainf* implementation such that it can be used to
implement Python, but can't be used to read or arbitrary files from
your file system? Will you reimplement the Python standard library in
Brainf*? Will you implement open(), but nerf it? Will you make sure
there's nothing anywhere in the stdlib that can open files? And if you
_don't_ provide a reimplemented standard library, you either need to
provide an import mechanism (so you can make use of the existing
Python code) or declare that the language as a whole is neutered by a
complete lack of all those features that are implemented in Python.

ChrisA

[toc] | [prev] | [next] | [standalone]

#91547

Chris Angelico <rosuav@gmail.com> writes:
> Turing completeness isn't the whole story. How do you go about
> sandboxing a Brainf* implementation such that it can be used to
> implement Python, but can't be used to read or arbitrary files from
> your file system?

We're talking about sandboxing, so preventing the sandboxed Python
interpreter written in embedded BF from accessing arbitrary files is the
whole point.  If you want to let a sandboxed program access a file, you
create some kind of managed handle outside the interpreter, and pass
that into the interpreter so the interpreted program can make a
constrained set of calls on it.  That's how Java applets work and it's
basically the opposite of Python's "consenting adults" approach which is
to let everything access everything.

[toc] | [prev] | [next] | [standalone]

#91543

In a message of Sat, 30 May 2015 20:42:49 +0200, Stefan Behnel writes:

>So here the cost of security is actually rewriting the entire language
>runtime and potentially also major parts of its ecosystem? Not exactly a
>cheap price either.
>
>Stefan

Well, the runtime is mostly generated, you don't have to write it by
hand.  But, yes, writing an interpreter is work, no question.  I think
that the problem of writing an interpreter is a much smaller proposition
than playing whack-a-mole with language level sandboxing, but depending
on your language, I could be wrong about that.

Laura

[toc] | [prev] | [next] | [standalone]

#91527

On 29/05/2015 23:49, Chris Angelico wrote:
> On Sat, May 30, 2015 at 4:33 AM, Paul Rubin <no.email@nospam.invalid> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>>> Looks to me as if Lua doesn't have integers at all
>>
>> They fixed that in Lua 5.3:
>>
>>    http://www.lua.org/manual/5.3/readme.html#changes
>
> That's 64-bit integers, not arbitrary-precision, but that's something
> at least. You do still need to worry about what happens when your
> numbers get too big; in Python, you simply don't. So it's still not
> quite there in terms of functionality.

But then the vast majority of integer operations won't require arbitrary 
precision. (Or maybe Python programmers routinely use big integers all 
over the place simply because they can.)

>>> Likewise, eight-bit strings, not Unicode.
>>
>> Also fixed in 5.3 (basic utf-8 support added, per above).

> Do you see what I mean about functionality being sacrificed for
> security? There is no way that this could be called fully functional
> by comparison with Python.

Python seems to have sacrificed some performance. When I questioned why 
3.x was slower than 2.x, merging int and long int (as I understood it) 
was one of the reasons put forward.

(Simplicity seems to work for Lua. The entire distribution (for LuaJIT 
2.0), seems to be about 2MB, including C sources, and the JIT 
interpreter is about 220KB. LuaJIT was also one of the fastest dynamic 
languages I've tried. But you're right that the language is rather sparse.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#91530

On Sat, May 30, 2015 at 10:06 PM, BartC <bc@freeuk.com> wrote:
> On 29/05/2015 23:49, Chris Angelico wrote:
>> That's 64-bit integers, not arbitrary-precision, but that's something
>> at least. You do still need to worry about what happens when your
>> numbers get too big; in Python, you simply don't. So it's still not
>> quite there in terms of functionality.
>
>
> But then the vast majority of integer operations won't require arbitrary
> precision. (Or maybe Python programmers routinely use big integers all over
> the place simply because they can.)

It's true that it won't often be an issue, but it's a matter of never
needing to worry about it. Have you ever had to tweak an algorithm to
ensure that you never go past some arbitrary boundary? In Python, with
pure integer arithmetic, you can guarantee that mathematical truths
are going to be maintained. There might still be good reason for doing
operations in one order rather than another, but it's to do with
performance, not correctness; the simple and naive algorithm can be
used to verify correctness of any smarter algorithm. That's an
important feature.

> Python seems to have sacrificed some performance. When I questioned why 3.x
> was slower than 2.x, merging int and long int (as I understood it) was one
> of the reasons put forward.

Yes, but that's an API point. A future version of Python could
re-separate them as an optimization, as long as script-level code
can't tell the difference. That's how Pike works, for instance; its
native "int" type handles both machine words and bignums, with no
visible distinction except performance. The common case (small
numbers) is optimized; but short of probing for timings, there's no
way to notice the actual boundary between the two. [1] This kind of
change could be done to a future Python without breaking any existing
code, and without breaking the expectation that integer arithmetic can
go to infinity.

ChrisA

[1] Well, Pike also has a constant Int.NATIVE_MAX, in case a program
is curious. But you get the idea.

[toc] | [prev] | [next] | [standalone]

#91437

Chris Angelico schrieb am 29.05.2015 um 09:41:
> On Fri, May 29, 2015 at 4:18 PM, Stefan Behnel wrote:
>>> Lua's a much weaker language than Python is, though. Can it handle
>>> arbitrary-precision integers? Unicode? Dare I even ask,
>>> arbitrary-precision rationals (fractions.Fraction)?
>>
>> All of those and way more, as long as you use it embedded in Python.
> 
> Okay, so how would you go about using Lua-embedded-in-Python to
> manipulate Unicode text?

Lua only supports byte strings, so Lupa will encode and decode them for
you. If that's not enough, you'll have to work with Python Unicode string
objects through the language interface. (And I just noticed that the
handling can be improved here by overloading Lua operators with Python
operators - not currently implemented.)


> Looks to me as if Lua doesn't have integers at all

The standard number type in Lua is a C double float, i.e. the steady
integer range is somewhere within +/-2^53. That tends to be enough for a
*lot* of use cases. You could change that type in the Lua C code (e.g. to a
64 bit int), but that's usually a bad idea. The same comment as above
applies: if you need Python object features, use Python objects.

Embedding Lua in Python gives you access to all of Python's objects and
ecosystem. It may not always be as cool to use as from Python, but in that
case, why not code it in Python in the first place? You wouldn't use
Lua/Lupa to write whole applications, just the user defined parts of them.
The rest can happily remain in Python. And should, for your own sanity.

Stefan

[toc] | [prev] | [next] | [standalone]

#91438

On Fri, May 29, 2015 at 7:23 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> Chris Angelico schrieb am 29.05.2015 um 09:41:
>> On Fri, May 29, 2015 at 4:18 PM, Stefan Behnel wrote:
>>>> Lua's a much weaker language than Python is, though. Can it handle
>>>> arbitrary-precision integers? Unicode? Dare I even ask,
>>>> arbitrary-precision rationals (fractions.Fraction)?
>>>
>>> All of those and way more, as long as you use it embedded in Python.
>>
>> Okay, so how would you go about using Lua-embedded-in-Python to
>> manipulate Unicode text?
>
> Lua only supports byte strings, so Lupa will encode and decode them for
> you. If that's not enough, you'll have to work with Python Unicode string
> objects through the language interface. (And I just noticed that the
> handling can be improved here by overloading Lua operators with Python
> operators - not currently implemented.)
>
>
>> Looks to me as if Lua doesn't have integers at all
>
> The standard number type in Lua is a C double float, i.e. the steady
> integer range is somewhere within +/-2^53. That tends to be enough for a
> *lot* of use cases. You could change that type in the Lua C code (e.g. to a
> 64 bit int), but that's usually a bad idea. The same comment as above
> applies: if you need Python object features, use Python objects.

Unicode strings shouldn't involve the hassle of bouncing through an
interface layer. Nobody will bother, and the result will be code
that's ASCII-only. That happens often enough even in Python 2, where
u"foo" is a Unicode string.

> Embedding Lua in Python gives you access to all of Python's objects and
> ecosystem. It may not always be as cool to use as from Python, but in that
> case, why not code it in Python in the first place? You wouldn't use
> Lua/Lupa to write whole applications, just the user defined parts of them.
> The rest can happily remain in Python. And should, for your own sanity.

The point was to sandbox something inside Python. Otherwise, yes, just
write it in Python. But if you do have to sandbox like this, you lose
language-level Unicode support, language-level arbitrary precision
integers, etcetera, etcetera, etcetera. So I stand by my previous
statement: The price of security is functionality.

ChrisA

[toc] | [prev] | [next] | [standalone]

#91440

In a message of Fri, 29 May 2015 19:38:21 +1000, Chris Angelico writes:
>The point was to sandbox something inside Python. Otherwise, yes, just
>write it in Python. But if you do have to sandbox like this, you lose
>language-level Unicode support, language-level arbitrary precision
>integers, etcetera, etcetera, etcetera. So I stand by my previous
>statement: The price of security is functionality.
>
>ChrisA

You can run a pypy sandbox from inside your CPython app, if that
is what you want to do.  http://pypy.readthedocs.org/en/latest/sandbox.html

Just FYI.

Laura

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web