Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redis-cli: permissions when opening history file #3284

Closed
kpcyrd opened this issue May 30, 2016 · 7 comments
Closed

redis-cli: permissions when opening history file #3284

kpcyrd opened this issue May 30, 2016 · 7 comments

Comments

@kpcyrd
Copy link

kpcyrd commented May 30, 2016

redis-cli saves it's history here:

https://github.com/antirez/redis/blob/8c4f4d12d856e57534277c1737d7cb07890bbe63/src/redis-cli.c#L1290

and uses the linenoise library to fopen the file there:

https://github.com/antirez/redis/blob/e0eb5f6bbf2407c802a231594acb90aa7a6a8e9a/deps/linenoise/linenoise.c#L1163

If the file does not exist, it's created with default umask 0022, so the file ends up with 0644. redis-cli writes it's history to ~ by default, which usually expands to a folder in /home, which is world accessible by default in a lot of distributions. This causes the file to be world readable.

You could either call umask to change the default permissions or pass appropriate permissions when creating, like bash does:

          file = open (hf, O_CREAT | O_TRUNC | O_WRONLY, 0600);

http://git.savannah.gnu.org/cgit/bash.git/tree/bashhist.c?id=ae339e9c3c855a2bbd8f8667d4cf2999e3f06bfa#n385

@kpcyrd
Copy link
Author

kpcyrd commented Jul 23, 2016

@antirez any news?

@kpcyrd
Copy link
Author

kpcyrd commented Jul 25, 2016

@lamby
Copy link
Contributor

lamby commented Jul 28, 2016

This has been given CVE-2013-7458

@lamby
Copy link
Contributor

lamby commented Jul 28, 2016

Note that simply using chmod(2) (like one of the above linked dupes suggestions) on the file leaves a race condition, one needs a patch like https://gist.github.com/lamby/5252347e8f2545d985a027cf142f0f5f

@antirez
Copy link
Contributor

antirez commented Jul 29, 2016

Thanks @lamby, I just applied your patch to unstable and 3.2.

@antirez antirez closed this as completed Jul 29, 2016
@denisvm
Copy link

denisvm commented Aug 4, 2016

Hello folks, just one small note regarding forced chmod change, you won't allow the user to change the permissions of the file afterwards if he really wants to as the file permissions will be always reverted.

@lamby
Copy link
Contributor

lamby commented Aug 4, 2016

(indeed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants