[SERVER-11226] Mongod cannot use relative file paths for keyFile if --fork is enabled Created: 16/Oct/13  Updated: 11/Jul/16  Resolved: 24/Oct/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.4.6
Fix Version/s: 2.5.4

Type: Bug Priority: Major - P3
Reporter: Kyle Erf Assignee: Matt Dannenberg
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OSX 64, Linux 64


Operating System: Linux
Steps To Reproduce:

1.) set up a keyfile and all other necessary directories to run mongod

2.) Run

mongod --dbpath /data/db --logpath /tmp/log --keyFile  myKeyFile 

from the directory that contains your keyfile and assure that it is starting up properly

3.) Now run

mongod --dbpath /data/db --logpath /tmp/log --keyFile  myKeyFile --fork 

in the same directory and watch it fail

4.) Note that changing the myKeyFile path to be absolute allows mongod to start

Participants:

 Description   

When running a mongod with a keyfile given on the command line, both full file paths and file paths relative to the working directory are acceptable input for the keyFile argument. That is, both keyFile /home/usr/keys/myKeyFile and keyFile myKeyFile should both work, assuming myKeyFile exists in the working directory.

However, if one enables fork along with keyFile only the full directory path starting from root is acceptable. Using a local filepath from the working directory will result in

error getting file myKeyFile: No such file or directory

and cause mongo to fail on startup.



 Comments   
Comment by auto [ 24/Oct/13 ]

Author:

{u'username': u'dannenberg', u'name': u'matt dannenberg', u'email': u'matt.dannenberg@10gen.com'}

Message: SERVER-11226 fix --keyFile to work with relative path when --fork'd
Branch: master
https://github.com/mongodb/mongo/commit/50ec2a895783239dde6ed0d51ffa9d522e2bebf2

Comment by Daniel Pasette (Inactive) [ 17/Oct/13 ]

same fix as SERVER-8524?

Generated at Thu Feb 08 03:25:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.