[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: |
|
||||||||||||||||||||||||||||
| 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
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: |
| 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) |
| 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.
|
| 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:
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. |
| 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:
|
| Comment by Martin Bligh [ 22/Feb/16 ] |
|
I think leaving umask to the user is the normal UNIX semantic. |
| 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, |
| 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? |