A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Nextcloud asked in a poll at https://mastodon.social/@nextcloud@mastodon.xyz/115095096413238457 what database its users are running. Interestingly one fifth replied they don't know. Should people know better where their data is stored, or is it a good thing everything is running so smoothly people don't need to know what their software stack is built upon?
@kolorafa@lemmy.world I just don't see the use of discussing extremely theoretical scenarios. Most hacks and privilege escalations are usually a chain of unpatched vulnerabilities. Running an unpatched database with an application on a server that is protected against all zero days is not what the real world looks like, so I don't see why you'd want to make it appear like it wasn't a big deal. A statement like that only lulls people who don't know any better into a false sense of security.
In a sense if you gain code execution on the application then you can just read the database credentials and authorize yourself to gain full access to data as those applications dont have any database access rules applied, so having exploitable database or not dont change anything.
But if we are talking about high security levels with complex inner-connected services with many apps connecting/talking to database or exposing database outside as a mistake, then yes, totally agree with you.
I'm not saying that you should use old db, Im just saying that you dont need to knoe what db is used in a scenario where app and database is a pre-packaged bundle, because when you update you update whole package so you update both, you are not in controll of the database used and you dont even need to know, what you need to know and do is to Update the whole bundle ASAP.
In case of Nextcould, if you install it from snap/flatpak or use some bundled all-in-one container then you don't know what database is used and even if you know, then it could be hard to to do anything about it, as it is the package maintainer responsibility to update it.
But if its docker-conpose with 2 containers one for db, you are fully responsible, but then most likely you will know it is using mysql/postgres because it would be in your face.
Also you can use external services like Hetzner offers, then you know that you are using nextcloud but you dont know what they did decided to use as database backed, you are paying for service! So, its like asking if you knoe which database is used by your lemmy instance that you use.
Long story short: (As a user) if the database is bundled in app in a way it is not accessible from outside and is updated togheter with app or you are paying for it as a service, you as a user not knowing what database is running or even if it is using database at all doesnt matter. Just make sure its up-to-date.
True, you have a valid point, about outdated version of database running in background, as it does matter when you breach the prevuous layers.
My example was a little overreaching, because it sounded like you personally chosing to run old version is fine. Or like it doesnt matter at all. Which is not true. It just matter way way less in comparison of running old/exploitable part that is exposed directly to internet whout any protection.