This particular behaviour can occur because the process is disallowed to call fork() and can be done with setrlimit() (see RLIMIT_NPROC). There should be other protections, though, because forking a "ls" is not the only way to access the filesystem.
Execv'ing processes is OK as long as you don't fork:
__import__("os").execv("/usr/bin/uname", ["uname", "-a"])
Linux ip-10-196-3-111 2.6.32-amazon-xen-r3 #1 SMP Mon Jan 16 21:03:16 PST 2012 i686 GNU/Linux
As for the actual files, there are a few clues that a chroot is created for every request : /proc is not mounted, /etc is minimal (root + 1 user in passwd) and "ls -id /" returns a new inode number every time.
adam.py... :) If only I knew more about bytecode...
import inspect
import pprint
pp = pprint.PrettyPrinter(depth=6)
f = inspect.currentframe()
c = 0
while f is not None:
c += 1
if c == 20:
print f.f_code
pp.pprint(dict(inspect.getmembers(f.f_code)))
f = f.f_back
Comments
This particular behaviour can occur because the process is disallowed to call fork() and can be done with setrlimit() (see RLIMIT_NPROC). There should be other protections, though, because forking a "ls" is not the only way to access the filesystem.
Ah, interesting.
File system access isn't blocked completely:
__import__("os").listdir("/evaluate")
open("/evaluate/test.py").readlines()
Execv'ing processes is OK as long as you don't fork:
As for the actual files, there are a few clues that a chroot is created for every request : /proc is not mounted, /etc is minimal (root + 1 user in passwd) and "ls -id /" returns a new inode number every time.Yeah, we are using chroot (along with other things) to sandbox things on a per request basis.
- Tejas from Team PythonMonk (I built the sandboxing stuff)
__import__("os").execv("/usr/bin/env", ["env"])
Gives you a few clues as well
adam.py... :) If only I knew more about bytecode...