[SERVER-41633] Ability to assign audit file permissions based on mongod's user group (not user) Created: 11/Jun/19  Updated: 29/Oct/23  Resolved: 16/Aug/19

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

Type: New Feature Priority: Major - P3
Reporter: barak gilboa Assignee: Sara Golemon
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Capture.PNG    
Issue Links:
Documented
is documented by DOCS-12960 Investigate changes in SERVER-41633: ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Security 2019-07-01, Security 2019-07-15, Security 2019-07-29, Security 2019-08-26
Participants:

 Description   

Current audit configuration: 

auditLog: 
    destination: file 
    format: JSON 
    path: /data/mongodb/audit/mongo_audit.log 

Files are rotated using SIGUSR1 to the mongod's PID. 

When using the audit feature, we want the audit file to have r/w permissions for the mongod group and not only the mongod user itself.

Nowadays we are using the flag  honorSystemUmask:true , but we want to eliminate it for not all the users on the machine will have access to it



 Comments   
Comment by Githook User [ 16/Aug/19 ]

Author:

{'username': 'sgolemon', 'email': 'sara.golemon@mongodb.com', 'name': 'Sara Golemon'}

Message: SERVER-41633 Allow overriding system umask for group/other from process startup

CodeReview: 488750005
Branch: master
https://github.com/mongodb/mongo/commit/ea1dd7a54b7b7bcae7f9ad15a547ed0ee3d4348b

Comment by Danny Hatcher (Inactive) [ 29/Jul/19 ]

barak.gilboa@imperva.com, would you be able to provide your use case?

Comment by Spencer Jackson [ 25/Jun/19 ]

Our artificial umasks are restrictive in order to provide more secure defaults.
It sounds like the fundamental issue you are experiencing is related to umask management, and I'm interested in capturing information about your use case. Can you describe why it is not feasible for you to change the umask of the process?

Comment by barak gilboa [ 25/Jun/19 ]

Is it on purpose that you don't want to give read permission to the mongod group?
It's not feasible for us to change the umask of the process.

Comment by Spencer Jackson [ 24/Jun/19 ]

barak.gilboa@imperva.com I believe it should be possible to obtain the desired behavior by enabling honorSystemUmask, and then configuring a non-default umask for your server process. To obtain your desired set of permissions of 660 for newly created files, you should be able to set your umask to 117.

Comment by barak gilboa [ 23/Jun/19 ]

Hi Jackson.

As described above, the reason we don't want to use the honorSystemUmask  flag is that we don't want to let all the users on the machine to have permissions to watch this file.
For that we want the created file to have R/W only for the user it self and its group (660).

Thanks,

Barak

 

Comment by Spencer Jackson [ 18/Jun/19 ]

The behavior you are observing was explicitly implemented to provide secure defaults in SERVER-11887 and SERVER-36977. honorSystemUmask is intended to allow administrators to override the defaults, if need be.

Unfortunately, I don't believe that overriding filesystem permissions independently of system umasks is feasible because changing permissions in a platform independent way is difficult, and the APIs used by auditing do not support POSIX permissions at all.

So that I can better understand your issue, barak.gilboa@imperva.com, could you explain the issues that you are having with honorSystemUmask?

Comment by Eric Sedor [ 11/Jun/19 ]

Thanks barak.gilboa@imperva.com; I am going to send this to an appropriate team for consideration. You can watch this ticket for updates.

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