[SERVER-22829] WiredTiger data files world-readable Created: 05/Nov/15  Updated: 01/Jan/19  Resolved: 18/Aug/17

Status: Closed
Project: Core Server
Component/s: Security, Storage
Affects Version/s: None
Fix Version/s: 3.5.12

Type: Bug Priority: Major - P3
Reporter: Andreas Nilsson Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on WT-3420 Add ability to choose file permission... Closed
Documented
is documented by DOCS-10737 Docs for SERVER-22829: WiredTiger dat... Closed
Duplicate
Related
related to SERVER-11887 Default file permissions on mongod an... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Platforms 2017-08-21
Participants:

 Description   

The WiredTiger data files in the data directory are given permissions

 666 xor umask 

As rad as this number is, unless there is a pressing reason for more open permissions we should probably change it to 600 since that is what mmapv1/legacy mongo does.



 Comments   
Comment by Githook User [ 18/Aug/17 ]

Author:

{'username': 'acmorrow', 'email': 'acm@mongodb.com', 'name': 'Andrew Morrow'}

Message: SERVER-22829 Strip group and other permissions on startup unless overridden
Branch: master
https://github.com/mongodb/mongo/commit/b3ad5d465cd2fec4983ff84be9da2cc06c1dac97

Comment by Alexander Gorrod [ 12/Jul/17 ]

Upon conversation with keith.bostic I've realized that the approach I outlined isn't right.

The right approach is for MongoDB to select an appropriate umask and apply it prior to calling wiredtiger_open - doing that will result in new files having the expected permissions, and allows for MongoDB to use consistently permissioned files across all components in the system.

backlog-server-platform this feels more like a platforms issue than a storage issue - there are other components in MongoDB than storage that create files.

Comment by Alexander Gorrod [ 10/Jul/17 ]

keith.bostic I believe WiredTiger should at least provide MongoDB the opportunity to configure the behavior - to that end I've opened (and linked) WT-3420. Once that work is done we should revisit this ticket.

Comment by alex [ 07/Jul/17 ]

@Keith Bostic, hi.

It'll be superfluous(I've already created a security issue with detailed explanation), so I'll be concise here: nobody will believe that this issue is even possible and is unresolved from 2015 unless he sees it with his own eyes. Definitely MongoDB inc is a great company and this happened only because you work too hard to make a great product and sometimes forget about vacation. You can fix this. I believe in you.

Captain's here: Without doubt all files should be created with zero "o" flag. Maybe using umask(S_IRWXG | S_IRWXO) like postgres does is too restrictive, especially if there is any software that requires access to files, but 0660 would be enough for any debuggin|backup tools. MongoDB also can accept something like MONGODB_UMASK, MONGODB_UMASK_DIR env. variables. o+r can be useful only for attacker whose intentions are to steal db files.

  • flies away *
Comment by Keith Bostic (Inactive) [ 07/Jul/17 ]

alexbyk, can you please give us some details of the problems you saw and why they occurred?

Comment by alex [ 07/Jul/17 ]

Faced this issue a couple of hours ago. In my case this was a big security vulnerability. I was very surprised and right now I'm even more surprised to see Created: 2015.

Comment by Martin Bligh [ 24/Feb/16 ]

Summary of discussion with Keith:

  • WT is a library and it's appropriate to avoid setting policy here, so they use the most liberal setting to leave it to the user
  • umask is traditionally for the user.
  • current setup combined with default Linux umask of 0002 defaults to world-readable files which relies too much on the user.
  • distros should be creating the db directory with more restrictive permissions (eg 750)
  • want to avoid yet more tweakable knobs if possible.
  • we have to deal with other storage engines, directories etc.

Seems like the best compromise would be to or current users umask with 0007 (which will stop us giving any permissions to "other" by default). Not convinced it's worth the extra complexity of making this tweakable - people wanting to do backups / debug as a separate user are better served by using groups, not world-readability.

Comment by Martin Bligh [ 24/Feb/16 ]

Moved to a SERVER- ticket instead of WT-. We have to do the right thing for other storage engines, files and directories.

Comment by Martin Bligh [ 23/Feb/16 ]

keith.bostic not really - I think the normal situation is that the umask belongs to the user to set, not the application.
Not sure why we'd alter that rather than just change the base permission we're creating with?

Comment by Keith Bostic (Inactive) [ 22/Feb/16 ]

andreas.nilsson, it sounds to me like martin.bligh is also inclined to have mongod set the umask. (Martin, is that correct?)

I think that makes the most sense for a couple reasons:

  • if mongod wants created files to have a restricted mode, it's not just WiredTiger files that should be created in a restricted mode, it should be all files created by mongod,
  • and, I assume mongod wants files created by all engines to be opened in a restricted mode, and any API added to WiredTiger wouldn't be available in RocksDB, for example.
Comment by Martin Bligh [ 22/Feb/16 ]

I think leaving umask to the user is the normal UNIX semantic.
I can see 640 or 660 making sense ... 666 does seem oddly overpermissive ...

Comment by Andreas Nilsson [ 22/Feb/16 ]

I stick with my original statement when filing the ticket.

I can't really make an assessment of the discussion above or choose between a umask, adding a WT option for mode or some other option.

cc martin.bligh is probably a better candidate to weigh in here.

Comment by Keith Bostic (Inactive) [ 21/Feb/16 ]

andreas.nilsson, WT-2201 has stalled, and I wanted to check in with you. Do you still believe there should be a WiredTiger change?

Comment by Keith Bostic (Inactive) [ 06/Nov/15 ]

michael.cahill, we could crack a string "rwrwrw" instead of messing with octal?

Comment by Keith Bostic (Inactive) [ 06/Nov/15 ]

redbeard0531, I think it's nastier than that, the directory permissions allow you to remove the data files and replace them with different data files.

I would agree that tightening down data file permissions means the files cannot be read in some cases (and I have no objection to doing that in some configurable way), but I don't think we've significantly increased security by the change.

Should MongoDB be doing a check on the directory permissions?

Comment by Michael Cahill (Inactive) [ 06/Nov/15 ]

The issue here isn't concurrent access, it's that other uses of WiredTiger might want users within a group to be able to access the same database (serially). I don't know of any such application currently using WiredTiger, but we faced this kind of issue in previous lives.

Could mongod just call umask? That would get the protection you're talking about consistently regardless of storage engine. If this would cause problems, presumably they are potential leaks of sensitive information?

We could certainly add an open_mode option to wiredtiger_open that would default to "0666" to avoid breaking existing WiredTiger apps. Unfortunately we don't currently support octal values in config strings so it would be a little awkward, but we could make it work. I think keith.bostic just wants to be sure that the requirements are clear before committing to an approach.

Comment by Andreas Nilsson [ 05/Nov/15 ]

I don't see how concurrent write access to the datafiles might be desirable. I could possibly stretch to 640 making sense, or make it configurable in wiredtiger_open?

In all fairness the user can set the umask to anything. However I'm mostly concerned with the change in behavior.

Comment by Mathias Stearn [ 05/Nov/15 ]

The directory permissions allow you to see what files exist, but do not let you access them. It doesn't seem like we should assume that everyone that is allowed to see which files exist should be allowed to look inside the files. As an example, /etc is world readable but /etc/shadow (which contains the encrypted passwords) isn't.

Comment by Keith Bostic (Inactive) [ 05/Nov/15 ]

I haven't thought about this much, so forgive me if I'm missing the obvious... but if the directory permissions allow group access, and we don't allow group access, haven't we prevented a reasonable configuration from working?

Comment by Andreas Nilsson [ 05/Nov/15 ]

I agree, the enclosing directory permissions should be restrictive. However I doubt that they are always set correctly.

My concern is that when we are changing to WT as default, we are also changing the default behavior of the data files to more permissive unless you have taken specific steps to protect the data directory.

Comment by Keith Bostic (Inactive) [ 05/Nov/15 ]

Can you go into more detail about the problem this fixes?

If the enclosing directory permissions aren't correct and sufficient, aren't we already in trouble?

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