permissions about docker-lambda HOT 24 CLOSED

Or this?

sudo apt-get install --install-recommends linux-image-generic-hwe-16.04 

from docker-lambda.

@corymickelson hmmm, that sounds like a bug – may have been from recent changes – lemme check

from docker-lambda.

Hmmm, this seems to work fine for me:

docker run --entrypoint bash lambci/lambda -c "echo test > /tmp/test.txt && cat /tmp/test.txt"

Lemme check if something's happening with the node process

from docker-lambda.

@corymickelson I can't reproduce this. The following works for me without any permission issues:

var fs = require('fs')

exports.handler = function(event, context, cb) {
  fs.writeFileSync('/tmp/hello.txt', 'hello')
  cb(null, fs.readFileSync('/tmp/hello.txt', 'utf8'))
}

Is it possible to show me some code that will reproduce this?

from docker-lambda.

Closing. Happy to reopen if there's a reproducible case here 👍

from docker-lambda.

@mhart
Hi, i'm using ubuntu 16.04 with 4.4.0-65-generic kernel
and getting this:

$ docker run --entrypoint bash lambci/lambda -c "echo test > /tmp/test"
bash: /tmp/test: Permission denied

any other image working fine.

Looks like the issue is here:

$ docker run --entrypoint bash lambci/lambda -c "ls -l /"
total 60
dr-xr-xr-x   2 root         root 4096 Dec  8 19:47 bin
...
drwx------   2 sbx_user1051  495 4096 Feb 12 19:07 tmp
...

and for example:

$ docker run --entrypoint bash esergion/dokku-alt-postgresql -c "ls -l /"
...
drwxrwxrwt   2 root root 4096 авг.  13  2015 tmp
...

from docker-lambda.

Well those permissions on /tmp are correct (and match production Lambda)

I just don't get the same result:

$  docker run --entrypoint bash lambci/lambda -c "echo test > /tmp/test && cat /tmp/test"
test

Are you sure you're using the latest lambci/lambda image? Can you run a docker pull lambci/lambda just to be sure?

from docker-lambda.

Try this:

$ docker run --entrypoint whoami lambci/lambda
sbx_user1051

That should match the user that has permissions for /tmp

from docker-lambda.

Image is latest

$ docker pull lambci/lambda
Using default tag: latest
latest: Pulling from lambci/lambda
Digest: sha256:c9562cc2e3e7009607d89e74078105f5b9e32c61caf01c017733f8bcbd7645e6
Status: Image is up to date for lambci/lambda:latest
$ docker run --entrypoint whoami lambci/lambda
sbx_user1051
$ docker run --entrypoint bash lambci/lambda -c "echo test > /tmp/test && echo /tmp/test"
bash: /tmp/test: Permission denied

from docker-lambda.

So the sbx_user1051 user doesn't have permissions to write to a directory that it owns and has write permissions on? Wtf?

This must be an issue with Docker running on Ubuntu? I'm running in VirtualBox and have no problems.

Will have to dig into this further – if you can figure out what's going on, let me know – the Dockerfile specifically gives permissions and sets the user: https://github.com/lambci/docker-lambda/blob/master/nodejs4.3/run/Dockerfile#L13-L17

from docker-lambda.

What version of Docker are you running? I wonder if it's an AUFS issue? Apparently older versions of AUFS can have permissions problems. If you run docker info, what does it show?

Mine shows:

$  docker info
Containers: 41
 Running: 0
 Paused: 0
 Stopped: 41
Images: 256
Server Version: 1.13.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 512
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
...

Note the "Dirperm1 Supported: true" line – do you have that?

from docker-lambda.

I have 1.13.1

$ docker info
Containers: 19
 Running: 0
 Paused: 0
 Stopped: 19
Images: 9
Server Version: 1.13.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 64
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
...

Dirperm1 Supported: true - line exist

I am currently searching on docker's issues for similar problem, there are some of such kind. Will read further ..

from docker-lambda.

@esergion great, thanks. If you figure out a way around it, let me know – maybe it's just a matter of changing the order of the mkdir/chmod commands or something weird like that.

from docker-lambda.

Weird, I wonder if this is a related workaround – moving the directory away and moving it back again...? (will need to be root to move) moby/moby#783 (comment)

from docker-lambda.

So try this and let me know if it works:

docker run --name lambci-test --user root --entrypoint bash lambci/lambda -c 'mv /tmp /tmpnew && mv /tmpnew /tmp'

docker commit lambci-test lambci-test

docker run --entrypoint bash lambci-test -c 'echo test > /tmp/test && cat /tmp/test'

from docker-lambda.

So i found out this: docker/docker#1295#issuecomment-269058662

When ADD-ing or COPY-ing files to an image, those files are always owned by root. If you have a USER instruction in your Dockerfile, that may result in that user not being able to read, chown or chmod those files. This is expected behavior. A pull request for changing this behavior through a --user flag is currently reviewed; #28499

and moby/moby#28499 is not yet merged

from docker-lambda.

I think that's unrelated – I'm not ADD-ing or COPY-ing /tmp

from docker-lambda.

Yeah, but looks like this is similar behavior. Seems that those commands in Dockerfile is executed in some kind of other layer (don't know how the docker really works inside)

So try this and let me know if it works:

Yes, it's working fine after moving temp dir

from docker-lambda.

Ok, so if it's working fine after the weird move thing, I guess it's just a matter of figuring out if it works from the Dockerfile.

If you clone this repo, you should be able to build from the Dockerfiles. cd into nodejs4.3/run and then try editing Dockerfile so that it looks like this:

1. With the mv in the same command as the mkdir, etc:

FROM lambci/lambda-base

ENV PATH=/usr/local/lib64/node-v4.3.x/bin:/usr/local/bin:/usr/bin/:/bin \
    LD_LIBRARY_PATH=/usr/local/lib64/node-v4.3.x/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib \
    NODE_PATH=/var/runtime:/var/task:/var/runtime/node_modules \
    LAMBDA_TASK_ROOT=/var/task \
    LAMBDA_RUNTIME_DIR=/var/runtime \
    LANG=en_US.UTF-8

ADD awslambda-mock.js /var/runtime/node_modules/awslambda/build/Release/awslambda.js

RUN rm -rf /tmp && mkdir /tmp && chown -R sbx_user1051:495 /tmp && chmod 700 /tmp && mv /tmp /tmpnew && mv /tmpnew /tmp

WORKDIR /var/task

USER sbx_user1051

ENTRYPOINT ["/usr/local/lib64/node-v4.3.x/bin/node", "--max-old-space-size=1229", "--max-semi-space-size=76", "--max-executable-size=153", "--expose-gc", \
  "/var/runtime/node_modules/awslambda/index.js"]

Then, from that same directory:

docker build --pull -t lambci-test .

docker run --entrypoint bash lambci-test -c 'echo test > /tmp/test && cat /tmp/test'

If that doesn't work, let's try:

2. With the mv as a separate layer:

FROM lambci/lambda-base

ENV PATH=/usr/local/lib64/node-v4.3.x/bin:/usr/local/bin:/usr/bin/:/bin \
    LD_LIBRARY_PATH=/usr/local/lib64/node-v4.3.x/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib \
    NODE_PATH=/var/runtime:/var/task:/var/runtime/node_modules \
    LAMBDA_TASK_ROOT=/var/task \
    LAMBDA_RUNTIME_DIR=/var/runtime \
    LANG=en_US.UTF-8

ADD awslambda-mock.js /var/runtime/node_modules/awslambda/build/Release/awslambda.js

RUN rm -rf /tmp && mkdir /tmp && chown -R sbx_user1051:495 /tmp && chmod 700 /tmp
RUN mv /tmp /tmpnew && mv /tmpnew /tmp

WORKDIR /var/task

USER sbx_user1051

ENTRYPOINT ["/usr/local/lib64/node-v4.3.x/bin/node", "--max-old-space-size=1229", "--max-semi-space-size=76", "--max-executable-size=153", "--expose-gc", \
  "/var/runtime/node_modules/awslambda/index.js"]

And then the same test:

docker build --pull -t lambci-test .

docker run --entrypoint bash lambci-test -c 'echo test > /tmp/test && cat /tmp/test'

from docker-lambda.

Ok, it's working fine after kernel upgrade to 4.8.
According to this and this comments it's a kernel bug.
Thanks a lot for helping me with this!

from docker-lambda.

Woah – nice one.

So basically, you fixed it by doing this?

sudo apt-get install --install-recommends xserver-xorg-hwe-16.04

from docker-lambda.

Ok, so i'll make little summary for my case:
Ubuntu 16.04 (upgraded from 15.10)
Kernel: 4.4.0-65-generic
Docker: 1.13.1

The fix was to upgrade the kernel to 4.8 where bug is fixed already
I made it like this sudo apt install --install-recommends xserver-xorg-hwe-16.04

from docker-lambda.

Thanks @esergion – a very annoying little bug for sure!

from docker-lambda.

sudo apt-get install linux-image-generic-hwe-16.04 is enough to install latest kernel on ubuntu and fixed the issue for me.

from docker-lambda.