Permission Denied on RDB file

[leond08]

I ' am getting an error on your docker image says "Permission Denied"

Here is my docker-compose.yml config

version: '3'
services:

  #Redis Service
  redisserver:
    image: redis:5.0.6-alpine
    container_name: redisserver
    restart: always
    tty: true
    ports: 
      - "6379:6379"
   working_dir: /data
    volumes:
      - redisdata: /data
      - /etc/localtime:/etc/localtime
    networks:
      - app-network
 

#Docker Networks
networks:
  app-network:
    driver: bridge

#Volumes
volumes:
  redisdata:
    driver: local

Here is the error i encounter

Failed opening the RDB file dump.rdb (in server root dir /etc/crontabs) for saving: Permission denied

[wglambert]

The entrypoint script applies appropriate permissions to the $WORKDIR, which in your case is working_dir: /data
It seems the config dir has changed to /etc/crontabs. Starting your docker-compose.yml everything looks normal

$ docker-compose up -d 
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "redis_app-network" with driver "bridge"
Creating volume "redis_redisdata" with local driver
Creating redisserver ... done

$ docker exec -it redisserver ash

/data # redis-cli config get dir
1) "dir"
2) "/data"

What's the output when you run redis-cli config get dir? If it's not /data as you've set; that would be an indication that your redis instance has been compromised
#128 (comment)
#44 (comment)

[TrungKhoaLe]

In the case of Redis being compromised, do you have any suggestion to resolve the issue?

[wglambert]

The best option is to just scrap that container/volume and start a new clean one. You could also try searching through the kdevtmpfsi issues, some opt to try manually deleting the malware.

But yeah as noted in https://github.com/docker-library/docs/tree/master/redis#security

It is highly recommended to set a password (by supplying a config file) if you plan on exposing your Redis instance to the internet.

And #140 (comment) it is very easy to "hack" a redis server and change files: http://antirez.com/news/96.

I successfully gained access as the Redis user, with a proper shell, in like five seconds. Courtesy of a Redis instance unprotected being, basically, an on-demand-write-this-file server, and in this case, by ssh not being conservative enough to deny access to a file which is all composed of corrupted keys but for one single entry. However ssh is not the problem here, once you can write files, even with binary garbage inside, it’s a matter of time and you’ll gain access to the system in one way or the other.