Failed opening the RDB file redis (in server root dir /etc/cron.d)

[Michael Brandonisio]

Hello, 

From Time to time I get this error over and over in my log file /var/log/redis/redis.log: 

14432:M 27 May 2019 10:50:02.110 # Background saving error 
14432:M 27 May 2019 10:50:08.026 * 1 changes in 900 seconds. Saving... 
14432:M 27 May 2019 10:50:08.027 * Background saving started by pid 4641 
4641:C 27 May 2019 10:50:08.027 # Failed opening the RDB file redis (in server root dir /etc/cron.d) for saving: Permission denied 

When I stop redis and then start redis it works a short while. Maybe a few days. 

I'm using Redis on CentOS 7.6 with redis version: 
Redis server v=5.0.5 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=619d60bfb0a92c36 

My dir value in redis.conf is /var/lib/redis 

It is not clear why it is looking in the /etc/cron.d folder. 

I use Redis with Owncloud and when this error comes up, OwnCloud will not allow sharing. 

Any direction would be appreciated. 

- Mike 

[Zhang Chao]

Hello!

Make sure that your Redis server is using the correct configuration file.

Maybe you can check the dir directive by CONFIG GET dir.

[Michael Brandonisio]

Hello,

I get this:

[root ~]# redis-cli

127.0.0.1:6379> CONFIG GET dir

1) "dir"

2) "/var/lib/redis"

127.0.0.1:6379> 

[tokers]

That's wired, this two values contradict each other ...

[Michael Brandonisio]

Yes very strange. Sort of why I posted it here hoping I could get pointed in the right direction.

[Greg Andrews]

Here's my best guess:

You're entering the CONFIG GET while your Redis instance is functioning properly, but you haven't run it while this error is occuring.  I have the feeling you will find that the running server's 'dir' parameter is '/etc/cron.d' while the error is being logged.

The cause?  Again, this is a guess:  Your Redis instance is somehow reachable from the world, and a malicious script is connecting to it and issuing commands to:

• Set your 'dir' to /etc/cron.d
• Write a key that will be interpreted as a cron.d entry (though the usual approach is an ssh authorized_keys file rather than a cron.d file)
• Schedule or invoke a background save, which will write a snapshot file to the 'dir' location
  

In the hope that your Redis is running as the privileged 'root' user and can create a file in /etc/cron.d that will be invoked by cron and the commands will grant the attacker privileged access to the server.  But your Redis server is running as some other user that can't write to /etc/cron.d, so it just breaks snapshots and eventually Redis functionality.

[Ajay Thakur]

May be write your own config file with minimal config and run the redis server.

and see if you hit the same error.

Thanks

Ajay

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/37a018d7-f6a7-44bb-93c5-c5fb2210b65a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

B Good. !

[Michael Brandonisio]

Hello, 

I had continued to research this and did see that 6379 was not supposed to open to the public. I have since closed the port in our filrewall. Since then it seems to be working as expected. 

I'll continue to monitor this. However, I think it was a my miss on the firewall setting allowing a hack attempt. 

Thanks for your help. 

- Mike