Running a local instance
raghu
I should be able to run the tool on my local machine using google app
engine's dev server. Right?
Thanks,
Raghu
Guido van Rossum
> I should be able to run the tool on my local machine using google app
> engine's dev server. Right?
the SDK is not designed with public hosting in mind, and if you use
the --address option, it will happily allow random strangers who can
connect to your machine to execute arbitrary Python code as yourself.
(This is otherwise a useful debugging feature. :-)
Raghuram Devarakonda
>
> On May 5, 10:55 am, raghu <draghu...@gmail.com> wrote:
> > I should be able to run the tool on my local machine using google app
> > engine's dev server. Right?
>
> Yes. However, please only do this for testing. The dev_appserver in
> the SDK is not designed with public hosting in mind, and if you use
Only for testing of course. On a separate note, I am apparently not in
the first 20000 requesters so I am still waiting for invite to google
app engine :-).
Mark Roddy
remotely with authenticated access, you can use the apache ProxyPass
module and apache authentication. I'm patiently awaiting an appengine
account as well, and I've found this to work out pretty well. If
you're interested I can post the configuration settings for doing so.
-Mark
On May 5, 3:24 pm, "Raghuram Devarakonda" <draghu...@gmail.com> wrote:
Ondrej Certik
On May 5, 11:19 pm, Mark Roddy <MarkRo...@gmail.com> wrote:
> As a work around if you want to access your local appengine instance
> remotely with authenticated access, you can use the apache ProxyPass
> module and apache authentication. I'm patiently awaiting an appengine
> account as well, and I've found this to work out pretty well. If
> you're interested I can post the configuration settings for doing so.
http://integrals.sympy.org/
here is the same app on google app engine:
http://sympy-live.appspot.com/
It's just the standard python shell demo + you can import my own
module (sympy). If you manage to hack it, please let me know (it's
running on a virtual server, so you don't have to worry, in the worst
case I'll just reinstall it). The apache configuration is this:
<VirtualHost *>
ServerName integrals.sympy.org
ServerAdmin <my email>
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
</VirtualHost>
And I simply run the ./dev_appserver.py as a regular user on the
default port. I know Guido said this setup is maybe not secure, but
I'd really like to figure out how I can run the same apps that run on
the google app engine myself, so that I am not depending on google if
I don't want to (and use google if I want to, like to get better
scalability, google authentication and other infrastructure).
Ondrej
Guido van Rossum
http://integrals.sympy.org/_ah/admin/interactive
I ran this little script in there:
x = __loader__
os = x.__init__.func_defaults[1]
p = os.popen("ls -l")
print p.read()
...
--Guido
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
http://code.google.com/appengine/docs/thedevwebserver.html#The_Development_Console
Ondrej Certik
>
> Did you know that this URL is always enabled (without requiring login)?
I noticed from the server logs. :)
> http://integrals.sympy.org/_ah/admin/interactive
>
> I ran this little script in there:
>
> x = __loader__
> os = x.__init__.func_defaults[1]
> p = os.popen("ls -l")
> print p.read()
Very cool! I was trying simple "os.system("ls")", but that didn't do
the trick, but your code did, thanks for the script. Yeah, I am going
to disable it and send a patch to the SDK.
BTW, I forgot to say I had to fix the timeout bug:
http://code.google.com/p/googleappengine/issues/detail?id=296
Ondrej
Guido van Rossum
>
> On Thu, May 8, 2008 at 8:38 PM, Guido van Rossum <gu...@python.org> wrote:
>>
>> Did you know that this URL is always enabled (without requiring login)?
>
> I noticed from the server logs. :)
>
>> http://integrals.sympy.org/_ah/admin/interactive
>>
>> I ran this little script in there:
>>
>> x = __loader__
>> os = x.__init__.func_defaults[1]
>> p = os.popen("ls -l")
>> print p.read()
>
> Very cool! I was trying simple "os.system("ls")", but that didn't do
> the trick, but your code did, thanks for the script. Yeah, I am going
> to disable it and send a patch to the SDK.
Hm, the SDK *intentionally* makes this always available -- the SDK is
meant to enable debugging your app. Note that requiring being logged
in as an admin user doesn't help -- the login code is fake too.
You should really focus on running your app *without* dev_appserver
but *with* the google.appengine package made available. (Some
initialization calls will be necessary, you can steal the code from
dev_appserver.)
> BTW, I forgot to say I had to fix the timeout bug:
>
> http://code.google.com/p/googleappengine/issues/detail?id=296
>
> Ondrej
>
> >
>
--
Ondrej Certik
>
> On Thu, May 8, 2008 at 11:49 AM, Ondrej Certik <ond...@certik.cz> wrote:
>>
>> On Thu, May 8, 2008 at 8:38 PM, Guido van Rossum <gu...@python.org> wrote:
>>>
>>> Did you know that this URL is always enabled (without requiring login)?
>>
>> I noticed from the server logs. :)
>>
>>> http://integrals.sympy.org/_ah/admin/interactive
>>>
>>> I ran this little script in there:
>>>
>>> x = __loader__
>>> os = x.__init__.func_defaults[1]
>>> p = os.popen("ls -l")
>>> print p.read()
>>
>> Very cool! I was trying simple "os.system("ls")", but that didn't do
>> the trick, but your code did, thanks for the script. Yeah, I am going
>> to disable it and send a patch to the SDK.
>
> Hm, the SDK *intentionally* makes this always available -- the SDK is
> meant to enable debugging your app. Note that requiring being logged
> in as an admin user doesn't help -- the login code is fake too.
Sure, I was meaning to create some commandline option for that.
>
> You should really focus on running your app *without* dev_appserver
> but *with* the google.appengine package made available. (Some
> initialization calls will be necessary, you can steal the code from
> dev_appserver.)
Right. I also need the restrictions, like disabling "open" and similar, which is
implemented in google/appengine/tools/dev_appserver.py, so I need this too.
Of course I don't know if there is some other possible hack to lift
those restrictions. Only then I'd have to consider patching the python
interpreter itself and creating some restricted python package,
possibly getting it to Debian.
Ondrej
Guido van Rossum
>>> Very cool! I was trying simple "os.system("ls")", but that didn't do
>>> the trick, but your code did, thanks for the script. Yeah, I am going
>>> to disable it and send a patch to the SDK.
>>
>> Hm, the SDK *intentionally* makes this always available -- the SDK is
>> meant to enable debugging your app. Note that requiring being logged
>> in as an admin user doesn't help -- the login code is fake too.
>
> Sure, I was meaning to create some commandline option for that.
I don't want to discourage you too much, but I'd vote against
including this in the SDK we distribute. Anything that might suggest
that it's cool to use the SDK for running a live app is a mistake IMO.
_ah/admin is just the tip of the iceberg.
>> You should really focus on running your app *without* dev_appserver
>> but *with* the google.appengine package made available. (Some
>> initialization calls will be necessary, you can steal the code from
>> dev_appserver.)
>
> Right. I also need the restrictions, like disabling "open" and similar, which is
> implemented in google/appengine/tools/dev_appserver.py, so I need this too.
No, if you just want to be able to deploy without depending on Google,
you don't need these restrictions. If you want to verify that your
code will still run on Google, just test it under the SDK.
> Of course I don't know if there is some other possible hack to lift
> those restrictions. Only then I'd have to consider patching the python
> interpreter itself and creating some restricted python package,
> possibly getting it to Debian.
That's not an easy task. Check out the sad history of Python's own rexec.py.
Ondrej Certik
>
> On Thu, May 8, 2008 at 12:11 PM, Ondrej Certik <ond...@certik.cz> wrote:
>>>> Very cool! I was trying simple "os.system("ls")", but that didn't do
>>>> the trick, but your code did, thanks for the script. Yeah, I am going
>>>> to disable it and send a patch to the SDK.
>>>
>>> Hm, the SDK *intentionally* makes this always available -- the SDK is
>>> meant to enable debugging your app. Note that requiring being logged
>>> in as an admin user doesn't help -- the login code is fake too.
>>
>> Sure, I was meaning to create some commandline option for that.
>
> I don't want to discourage you too much, but I'd vote against
> including this in the SDK we distribute. Anything that might suggest
> that it's cool to use the SDK for running a live app is a mistake IMO.
> _ah/admin is just the tip of the iceberg.
>
>>> You should really focus on running your app *without* dev_appserver
>>> but *with* the google.appengine package made available. (Some
>>> initialization calls will be necessary, you can steal the code from
>>> dev_appserver.)
>>
>> Right. I also need the restrictions, like disabling "open" and similar, which is
>> implemented in google/appengine/tools/dev_appserver.py, so I need this too.
>
> No, if you just want to be able to deploy without depending on Google,
> you don't need these restrictions. If you want to verify that your
> code will still run on Google, just test it under the SDK.
Well, my app is the shell, i.e. let's say I want to deploy this app:
so I think I need the restrictions, don't I?
>
>> Of course I don't know if there is some other possible hack to lift
>> those restrictions. Only then I'd have to consider patching the python
>> interpreter itself and creating some restricted python package,
>> possibly getting it to Debian.
>
> That's not an easy task. Check out the sad history of Python's own rexec.py.
Right. There were also other tries to make a sandboxed python.
However, if one wants to run the app without google, I think I need
the restrictions, because I don't want the app to be able to use
"open", "os.system" and other things. And of course I want to use the
google API, because this will hopefully become as a de facto standard
and also I want to make sure it still runs on google.
So I can see only two ways forward -- either patch the python
interpreter itself, and/or use some restrictions ala the SDK. So I'll
start with the SDK with a few changes, but if someone will manage to
hack it, I'll have to find some other way to run the app with the same
security as google is using.
Ondrej
Guido van Rossum
> Well, my app is the shell, i.e. let's say I want to deploy this app:
>
> http://shell.appspot.com/
>
> so I think I need the restrictions, don't I?
Don't bother -- those restrictions are never enough. There is no easy
way to make something like the shell app secure; this is one of the
parts of AppEngine that will not be easy to replicate elsewhere. (And
for *most* apps, it isn't necessary since if you host your own app on
your own box you don't have the threat model that AppEngine caters
to).
>>> Of course I don't know if there is some other possible hack to lift
>>> those restrictions. Only then I'd have to consider patching the python
>>> interpreter itself and creating some restricted python package,
>>> possibly getting it to Debian.
>>
>> That's not an easy task. Check out the sad history of Python's own rexec.py.
>
> Right. There were also other tries to make a sandboxed python.
>
> However, if one wants to run the app without google, I think I need
> the restrictions, because I don't want the app to be able to use
> "open", "os.system" and other things. And of course I want to use the
> google API, because this will hopefully become as a de facto standard
> and also I want to make sure it still runs on google.
>
> So I can see only two ways forward -- either patch the python
> interpreter itself, and/or use some restrictions ala the SDK. So I'll
> start with the SDK with a few changes, but if someone will manage to
> hack it, I'll have to find some other way to run the app with the same
> security as google is using.
I guarantee you that nothing you can try by writing pure Python code
will be enough to prevent people from breaking through your security.
Ondrej Certik
>
> On Thu, May 8, 2008 at 1:01 PM, Ondrej Certik <ond...@certik.cz> wrote:
>> Well, my app is the shell, i.e. let's say I want to deploy this app:
>>
>> http://shell.appspot.com/
>>
>> so I think I need the restrictions, don't I?
>
> Don't bother -- those restrictions are never enough. There is no easy
> way to make something like the shell app secure; this is one of the
> parts of AppEngine that will not be easy to replicate elsewhere. (And
> for *most* apps, it isn't necessary since if you host your own app on
> your own box you don't have the threat model that AppEngine caters
> to).
Unfortunately that's what I am mainly interested in -- being able to
play with a pure python library online in a shell. Also I want to make
sure if there is some bug in my python program, so that the attacker
won't gain too much by exploiting it.
>
>>>> Of course I don't know if there is some other possible hack to lift
>>>> those restrictions. Only then I'd have to consider patching the python
>>>> interpreter itself and creating some restricted python package,
>>>> possibly getting it to Debian.
>>>
>>> That's not an easy task. Check out the sad history of Python's own rexec.py.
>>
>> Right. There were also other tries to make a sandboxed python.
>>
>> However, if one wants to run the app without google, I think I need
>> the restrictions, because I don't want the app to be able to use
>> "open", "os.system" and other things. And of course I want to use the
>> google API, because this will hopefully become as a de facto standard
>> and also I want to make sure it still runs on google.
>>
>> So I can see only two ways forward -- either patch the python
>> interpreter itself, and/or use some restrictions ala the SDK. So I'll
>> start with the SDK with a few changes, but if someone will manage to
>> hack it, I'll have to find some other way to run the app with the same
>> security as google is using.
>
> I guarantee you that nothing you can try by writing pure Python code
> will be enough to prevent people from breaking through your security.
Well, then one needs to go the "patching the python interpreter" way.
http://wiki.python.org/moin/SandboxedPython
Some code can be found in the Brett Cannon's branch here:
http://svn.python.org/view/python/branches/bcannon-objcap/
One can try it like this:
$ svn co http://svn.python.org/projects/python/branches/bcannon-objcap/
$ cd bcannon-objcap
$ ./configure
$ make
$ ./build_secure_py.sh (I had to add a "-lutil" to the link phase)
Unfortunately, it doesn't seem to run:
$ ./secure_python.exe
Import of controlled_importlib failed.
This is triggered by these lines in secure_python.c:
/* Get importer from importlib. */
import_module = PyImport_ImportModule("controlled_importlib");
if (!import_module) {
fprintf(stderr, "Import of controlled_importlib failed.\n");
return 1;
}
So I need to find out what's wrong now.
Maybe it could serve as a start of a sandoxed interpreter.
Ondrej
Andi Albrecht
patch set via upload.py or using the form i got the following error:
Environment:
Request Method: POST
Request URL: http://localhost:8080/new
Django Version: 0.97-pre-SVN-7534
Python Version: 2.5.2
Installed Applications:
['codereview']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
'codereview.middleware.AddUserToRequestMiddleware')
Traceback:
File "/storage/devel/rietveld/django/core/handlers/base.py" in
get_response
82. response = callback(request, *callback_args,
**callback_kwargs)
File "/storage/devel/rietveld/codereview/views.py" in login_wrapper
271. return func(request, *args, **kwds)
File "/storage/devel/rietveld/codereview/views.py" in new
408. issue = _make_new(request, form)
File "/storage/devel/rietveld/codereview/views.py" in _make_new
500. return db.run_in_transaction(txn)
File "/storage/opt/google_appengine/google/appengine/api/datastore.py"
in RunInTransaction
1301. result = function(*args, **kwargs)
File "/storage/devel/rietveld/codereview/views.py" in txn
491. patchset.put()
File "/storage/opt/google_appengine/google/appengine/ext/db/
__init__.py" in put
603. return datastore.Put(self._entity)
File "/storage/opt/google_appengine/google/appengine/api/datastore.py"
in Put
153. _MaybeSetupTransaction(req, entities[0])
File "/storage/opt/google_appengine/google/appengine/api/datastore.py"
in _MaybeSetupTransaction
1390. this_group.kind(), id_or_name(this_group)))
Exception Type: BadRequestError at /new
Exception Value: Cannot operate on different entity groups in a
transaction: (kind=u'Issue', id=None) and (kind=u'Issue', id=5).
Did I miss something?
Thanks,
Andi
Guido van Rossum
of the SDK. Download SDK 1..0.2 from code.google.com/appengine and you
should be fine.
--