[SERVER-45895] mongocryptd creates socket and pid files in different locations Created: 30/Jan/20  Updated: 27/Oct/23  Resolved: 17/Jun/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Mark Benvenuto
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-41029 mongocryptd should not delete existin... Closed
Sprint: Security 2020-02-24, Security 2020-03-09, Security 2020-03-23, Security 2020-04-06, Security 2020-04-20, Security 2020-05-04, Security 2020-05-18, Security 2020-06-01, Security 2020-06-15, Security 2020-06-29
Participants:

 Description   

mongocryptd launched with the only argument of --idleShutdownTimeoutSecs=60 creates a socket file in /tmp and a pid file in the current directory:

2020-01-30T18:21:16.802-0500 I  CONTROL  [initandlisten] Using lock file: /home/w/apps/ruby-driver/mongocryptd.pid
2020-01-30T18:21:16.818-0500 I  NETWORK  [initandlisten] Listening on /tmp/mongocryptd.sock

Since both files are associated with the same process, they should be placed in the same principal location (either global to the system or local to the application launching mongocryptd/current directory).

As I understand it, mongocryptd is intended to be system-global/shared; if this is correct, I expect the pid file to be placed in a system-global/shared location as well (e.g. /var/run on systems obeying FHS, see http://www.pathname.com/fhs/2.2/fhs-5.13.html).

Tested on 4.2 server built from source recently.



 Comments   
Comment by Mark Benvenuto [ 20/Mar/20 ]

Yes, monocryptd reuses core components of the mongod code base. As a result, the unix socket behavior was inherited from the existing mongod implementation. In terms of /tmp usage, there are other daemons (i.e. systemd) that will write files to /tmp.

I provided flags to control the behavior but I left the behavior as the default for unix socket file. In terms of the pid file, you are correct that I defaulted it to the user behavior because mongocryptd is not supported as system-wide daemon.

Comment by Oleg Pudeyev (Inactive) [ 04/Mar/20 ]

My understanding of https://jira.mongodb.org/browse/SERVER-41029 is 41029 is caused by the same issue described in this ticket - mongocryptd attempts to acts as both a systemwide process and a local process, breaking both use cases to some extent (the use case described in 41029 is two local instances running concurrently).

Comment by Oleg Pudeyev (Inactive) [ 05/Feb/20 ]

The crux of this ticket is that mongocryptd currently, by default, behaves as both a user-specific process and a system-wide daemon.

A system-wide daemon generally expects to use well-known paths for its files. For example, it may create a socket as /tmp/mydaemon.sock. Applications are written to use these well-known paths without caring about, for example, which user account the daemon is running under (common examples for this being root, nobody or a designated user).

A user-specific process does NOT use global paths for its files because this would preclude two users running the process at the same time. Instead a user-specific process generally either writes under $HOME (and expects that the user has a writable $HOME) or creates a temporary directory in /tmp (with a generated name so that different invocations yield different paths).

mongocryptd does both by default - it cannot be executed by two different users (with no arguments, i.e. the default invocation) but the first successful invocation places the pid file into the current directory which is not discoverable by other applications or users.

Comment by Mark Benvenuto [ 04/Feb/20 ]

The pid file location can be controlled via `--pidfilepath`. The mongocryptd daemon leaves choosing a location to put the pid file to the program launching the mongocryptd daemon. I did not want to make assumptions as to where to put the file as it would depend on whether it is launched as a "normal" user or systemd/initd/etc daemon.

Comment by Oleg Pudeyev (Inactive) [ 04/Feb/20 ]

mongocryptd creating files in current directory makes it not work when started as a system-wide daemon with current directory of /:

speed% (cd / && sudo -u m /usr/local/m/versions/4.2/mongocryptd)
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] MongoCryptD starting : pid=20583 port=27020 socketFile=/tmp/mongocryptd.sock 64-bit host=speed
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] db version v4.2.1-23-g1860793
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] git version: 186079301dc9de56313f5a8e84e6088fec289ded
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] allocator: tcmalloc
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] modules: enterprise 
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] build environment:
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten]     distarch: x86_64
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten]     target_arch: x86_64
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] options: {}
2020-02-04T16:32:34.550-0500 I  CONTROL  [initandlisten] Using lock file: /mongocryptd.pid
2020-02-04T16:32:34.550-0500 E  CONTROL  [initandlisten] Failed to open pid file, exiting: IllegalOperation: Attempted to create a lock file on a read-only directory: /

Generated at Thu Feb 08 05:09:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.