Selfhosted
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.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Absolutely this. Even if you had fancy jails or docker setups for each submission, this will be a nightmare to properly handle. Students DOSing each other exactly before the submission deadline, too.
I mean just for the love of God don't spin up something on your company's infrastructure that accepts file uploads.
Just don't.
If you're reading this and going "well, it's just internal," or "well, it doesn't do much it just accepts this exact file type." My god. Ask your CISA. And if they're okay with it, cool. That's on them.
Unless your whole business is transferring files, don't. And even then... Don't.
And if you're still confused, the answer is to use another company's infrastructure for this. Use Azure. Use AWS. Use Google cloud or even g suites. Don't accept that liability. Let the trillionaires do it.
I mean if you put up an Internet-facing unauthenticated file acceptor it will quickly become stuffed with all sorts of garbage and aspiring malware. You definitely don't want to hook that up to an untar and exec loop, even with some notion of sandboxing. It will just start mining Bitcoins or sending spam or something.
But if it is built properly, with only authorized users being able to upload stuff, and a basic understanding of not dropping stuff where the web server will happily execute every PHP web shell someone sticks in the slot, and the leverage to threaten people into not uploading pictures of their own or others' butts or Iron Man (2009), I don't see why all but the file-uploading professionals should immediately give up.
Security noob here. Would it be sufficient (in addition to only local authorized access) to directly put the file in an unprivileged container, watching its log output? And of course limiting resource use and execution time of the container (don't know if common container tools like docker or podman have a way to limit resources out of the box)
So lets say a simple interface for the file upload behind an authentication service, based on lets say python cgi, ramping up an unprivileged nonroot docker container, killing the container after a fixed time (a few seconds).
Probably.