All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MongoDB makes databases world-readable by default
The next chapter in the continuing saga of MongoDB getting even the most basic aspects of a database wrong, and failing to fix it promptly...
If you have dedicated server/vps running multiple websites, or even worse, if you use a shared hosting with additional MongoDB installed, most probably you have security problems. You sleep well assuming that MongoDB authentication mechanism protects you the same way as MySql/Postgres does? Surprise!
By default mongodb’s directories and files are too permissive. Any user on the same server can just copy all your databases. Even if MongoDB isn’t accessible from the outside web (port is closed by firewall rules).
[...]
The ticket about this issue exists for a couple of years and looks like nobody is in hurry to fix it or nobody considers it as a security threat. So I decided you should at least know about it.
[...]
Source: https://medium.com/@alexbyk/mongodb-at-shared-hosting-security-surprises-c441ecb84b54
TL;DR: MongoDB databases (using WiredTiger) are created with 666 permissions by default - that is, everybody on the system can read and write every database.
Comments
Wasn't there an issue with the server binding on the public ip (instead of localhost) previously also?
Yeah. Also defaulting to "no authentication required".
Does this allow you to override existing databases or just copy?
Both, apparently, since it's also world-writable.
EDIT: Provided you replace the databases at the right moment and don't produce a corrupted database, of course.
But it's the only database that works with Node.JS and I need NoSQL which postgresql can't do!
(copy/pasted from "How to Troll @joepie91")
I see you've been paying attention... are you stalking me in #Node.js?
Seems like a rookie mistake from the user side. You shouldn't deploy MongoDB on a multi-user server in the first place. I mean we can debate all day about this, but I don't see an issue here. Just like any other DB of the thousands available, if production... then secure on try-hard mode.
Utter nonsense, and this is just inventing arbitrary excuses to justify a bad default. Deploying a database on a shared system is completely fine, that's what multitenancy on systems is for. If you feel it isn't, then feel free to motivate exactly why deploying a database on a multi-user server is bad, instead of just claiming that it is.
Those other databases set correct filesystem permissions by default.
could've stopped here
Mongo - "Learn to admin yourself, we shouldn't have to ship sane defaults" - DB
Really should be their motto. Sure an admin should always be aware of bad defaults and should be working to make things safe, but a commitment to defaults that are not sane is just not....sane.
People are still using Mongo at this point!? I'd say you probably deserve whatever befalls you.
Docker generation...
Document databases have a lot of benefits nowadays. There are many of them of course but MongoDB is quite popular, specially with full JS stack applications (front-end / back-end). I'm old school so I default to relational databases. There are some complicated setups around like using MongoDB as a cache to a extremely big relational database, etc.
Set your umask and it'll all be good.
No, they do not. The only people who believe they have "lots of benefits" (without very strictly qualifying that statement), are people who don't understand the inherent difficulties of dealing with data in a reliable manner, and laud MongoDB and consorts because it's "so easy".
In reality, it just looks easy, and that's because it sweeps a bunch of data integrity concerns under the carpet that will bite you in the ass down the road. Anything can be made to look easy by papering over the technical concerns and not caring about the outcome.
It's not like there's some kind of recent innovation in database technology here, either; all the technology in MongoDB has been around for a long time, but not widely deployed in production like this before - and for very good reason, because the technical tradeoffs do not make sense for 99.99% of the cases.
But hey, that doesn't stop a poorly informed startup crowd from hailing it as a revolution. Helped by a decent amount of marketing drivel, of course.
MongoDB isn't a cache. There are far better options for that, with less overhead.