In the AWS Lambda Shell Hack article, I present a crude hack that lets me run shell commands in the AWS Lambda environment to explore what might be available to Lambda functions running there.
I’ve added a wrapper that lets me type commands on my laptop and see the output of the command run in the Lambda function. This is not production quality software, but you can take a look at it in the alestic/lambdash GitHub repo.
For the curious, here are some results. Please note that this is running on a preview and is in no way a guaranteed part of the environment of a Lambda function. Amazon could change any of it at any time, so don’t build production code using this information.
The version of Amazon Linux:
$ lambdash cat /etc/issue
Amazon Linux AMI release 2014.03
Kernel \r on an \m
The kernel version:
$ lambdash uname -a
Linux ip-10-0-168-157 3.14.19-17.43.amzn1.x86_64 #1 SMP Wed Sep 17 22:14:52 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
The working directory of the Lambda function:
$ lambdash pwd /var/task
which contains the unzipped contents of the Lambda function I uploaded:
$ lambdash ls -l
total 12
-rw-rw-r-- 1 slicer 497 5195 Nov 18 05:52 lambdash.js
drwxrwxr-x 5 slicer 497 4096 Nov 18 05:52 node_modules
The user running the Lambda function:
$ lambdash id
uid=495(sbx_user1052) gid=494 groups=494
which is one of one hundred sbx_userNNNN users in /etc/passwd. “sbx_user” presumably stands for “sandbox user”.
The environment variables (in a shell subprocess). This appears to be how AWS Lambda is passing the AWS credentials to the Lambda function.
$ lambdash env
AWS_SESSION_TOKEN=[ELIDED]
LAMBDA_TASK_ROOT=/var/task
LAMBDA_CONSOLE_SOCKET=14
PATH=/usr/local/bin:/usr/bin:/bin
PWD=/var/task
AWS_SECRET_ACCESS_KEY=[ELIDED]
NODE_PATH=/var/runtime:/var/task:/var/runtime/node_modules
AWS_ACCESS_KEY_ID=[ELIDED]
SHLVL=1
LAMBDA_CONTROL_SOCKET=11
_=/usr/bin/env
The versions of various pre-installed software:
$ lambdash perl -v
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
[...]
$ lambdash python --version
Python 2.6.9
$ lambdash node -v
v0.10.32
Running processes:
$ lambdash ps axu
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
493 1 0.2 0.7 1035300 27080 ? Ssl 14:26 0:00 node --max-old-space-size=0 --max-new-space-size=0 --max-executable-size=0 /var/runtime/node_modules/.bin/awslambda
493 13 0.0 0.0 13444 1084 ? R 14:29 0:00 ps axu
The entire file system: 2.5 MB download
$ lambdash ls -laiR /
[click link above to download]
Kernel ring buffer: 34K download
$ lambdash dmesg
[click link above to download]
CPU info:
$ lambdash cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x416
cpu MHz : 2800.110
cache size : 25600 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5600.22
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
[...]
Installed nodejs modules:
$ dirs=$(lambdash 'echo $NODE_PATH' | tr ':' '\n' | sort)
$ echo $dirs
/var/runtime /var/runtime/node_modules /var/task
$ lambdash 'for dir in '$dirs'; do echo $dir; ls -1 $dir; echo; done'
/var/runtime
node_modules
/var/runtime/node_modules
aws-sdk
awslambda
dynamodb-doc
imagemagick
/var/task # Uploaded in Lambda function ZIP file
lambdash.js
node_modules
[Update 2013-12-03]
We’re probably not on a bare EC2 instance. The standard EC2 instance metadata service is not accessible through HTTP:
$ lambdash curl -sS http://169.254.169.254:8000/latest/meta-data/instance-type
curl: (7) Failed to connect to 169.254.169.254 port 8000: Connection refused
Browsing the AWS Lambda environment source code turns up some nice hints about where the product might be heading. I won’t paste the copyrighted code here, but you can download into an “awslambda” subdirectory with:
$ lambdash 'cd /var/runtime/node_modules;tar c awslambda' | tar xv
[Update 2013-12-11]
There’s a half gig of writable disk space available under /tmp (when run with 256MB of RAM. Does this scale up with memory?)
$ lambdash 'df -h 2>/dev/null'
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 1.9G 28G 7% /
devtmpfs 30G 1.9G 28G 7% /dev
/dev/xvda1 30G 1.9G 28G 7% /
/dev/loop0 526M 832K 514M 1% /tmp
Anything else you’d like to see? Suggest commands in the comments on this article.