

Yes that tracks with how OIDC setup works with my other services (you give the container the OIDC links and shared secrets so it knows how to talk to the OIDC and trust it).
Yes that tracks with how OIDC setup works with my other services (you give the container the OIDC links and shared secrets so it knows how to talk to the OIDC and trust it).
I am digging this, thanks for keeping it updated and improving it!
I see that you say it’s feature complete / no user stuff; but it’d really mesh well if it took OIDC authentication. Don’t need it to make users or anything, just instead of the password popup the OIDC provider is asked for confirmation that whatever user registered with the OIDC is logged in. That’d let me leverage extra 2FA protection from the OIDC provider and juice on that one-login life.
Now I have no experience making OIDC crap work nor how it even works behind the scenes, so I can’t help :( sorry; just wishful thinking.
Also saw on your github - hope our newly shit-out gestapo don’t bother you!
Not if you annotate your data volume with said ‘noexec’ which prevents execution from anything in the data volume. It looks like this, you can slam it on any volume you like - no volumes should have executables in them anyways.
Also I’m pretty sure ‘noexec’ is the default, so that’s by default protected. But I can’t confirm that from a quick search so not 100% on that.
‘/mnt/data:/container/place/it/wants:rw,noexec,nosuid,nodev,Z’
‘rw’ means read/write. You can change it to ‘ro’ for read-only if the volume shouldn’t write to it (maybe a config file).
Z is for selinux that means “only one program can read/write tho this”. You can change it to ‘z’ lowercase in case more than one needs to read/write. Only case I’ve found for little z is crowdsec needing to watch Caddy’s log for blocking.
So overall, the idea is that your volume mounts can’t be used to execute arbitrary binaries AND the image file system is frozen so that arbitrary binaries cannot be loaded into the image (which is by default all executable, a requirement to run anything in it). So if someone was able to hack into an internet-facing container, they won’t be able to load up whatever they want. They’ll be limited to what’s built into the image (which ideally are secure and limited in scope).
As always you store data you want to keep in the volumes section.
With read-only you prevent new binaries from being added in the image space. You can add ‘noexec’ to your volumes/tmpfs preventing binaries to the areas that are writable. Then ideally you are using an image with minimal surface area (e.g., only sh and the exact binaries needed to make it go) and it’s very secure! It’s still plenty secure without a minimal image.
Thanks! This’ll def help me get tooled up for podman :)
Care to share your quartet? I’m just getting into the quads with trixie out - and I haven’t gotten this working yet…
The permissions do seem intense; if you’re getting by without maybe those aren’t quite needed!
No what I said isn’t about user registration; it’s about adding these to the docker-compose.yml
:
read_only: true
user: 6969:6969
to prevent running as root and making the file system read-only. The API needs to be exposed without a VPN or other proxy login since my parents’ can’t handle that, so if I was able to implement these recommended security steps I’d feel like I could open up the container to the internet at large without too much risk.
Per this issue https://github.com/linkwarden/linkwarden/issues/799 it seems like there’s a lot of steps to take to get these settings to work.
It would be also ideal if I didn’t have to give the container (but not a deal-breaker):
cap_add:
- CAP_SYS_ADMIN
- CAP_SYS_CHROOT
as the issue also states is required for the headless chrome scraper browser.
I am using it internally now and it’s really good, but to open it up for my parents (which I think they’d dig) I’d definitely want these security settings on without major issues. Linkwarden is an internet-facing application so these recommended security practicies are in its wheel-house, feature-wise, as well.
Hope that helps clear up my comment!
This is a fantastic tool, but I’d love to confidently expose the API to the internet for the shortcut. To do that you need read-only and running as a user; I saw that that’s not a thing that works from the issues.
Any thoughts on getting those security features working? Cause the app itself is so smooth I’d let my parents use it and be confident they wouldn’t need to be herded constantly.
If you’ve got Debian already installed, I cannot resist advocating for Incus (stable branch from Zabbly repo with web ui https://blog.simos.info/how-to-install-and-setup-the-incus-web-ui/) in lieu of proxmox. Does the same thing but you don’t have to rip out the kernel Debian uses.
With Debian 13 you have access to podman quadlets, use that for any non-vm needs. The ease of docker compose files easily removes reason for programs in LXC containers, and podman removes reason for docker in an LXC. LXC is left only for programs that aren’t containerized. VMs for security DMZ. Podman for bulk of stuff you want.
Good luck!
My gloriously unionized USPS workers are hella pissed that I continue to write “no longer at address” on mail for the umpteen people who have previously lived where I am now. I will occasionally get mail with “or current resident” underlined many, many times because it was misdelivered and that person sent it back, and they think I tried to “no longer address” it I guess.
I lived in a newer development a few years ago and they didn’t care about names there either. Sad to hear new-new is different.
Overall, if your USPS just wants to jettison mail at an address, using a fake name is great. I get spam for shit with a fake name and I can see who sold my info (and ditch them). I get emails like “Shitbob Jimbo, we stole your identity and hacked your email and computer and it’s joever for you, believe us because we know your name.” Little do they know I’m really Jimshit Bimbo and forever elusive
I’ve lived in several states and USPS doesn’t care about your name. They want your legal name written on the mailbox (and will usually write it down if you don’t when you move in), but they will deliver to any ass name. I’ve used fake names for everything ever for a long time now and only had a problem once with an international shipment. You can mail random ass name to random ass address and they’ll put it at the address.
If USPS fails to deliver an international item that requires a signature, you need to show ID if they don’t try to redeliver. And your name must match or they won’t give it to you.
In my case, it was something that didn’t require a signature and even had a “no signature required” sticker on it from the sender because they do that enough apparently. And the USPS didn’t try to deliver it cause I have a cam. So the USPS person just gave it to me and told me to not fuck up again on international shipments and that was that!
In short, fake name good at all times except on international orders that require a signature.
Ignore the peeps saying not to use a regular pci-e card. Old recc, ASmedia ones are ideal good for 4-6 ports. 8+ you need to dabble in LSI shenanigans. The ASmedia ones use way less power and are worth it if you don’t need 8+ ports. You get all the features you want, they look and act like real SATA ports.
Check these guides (not just applicable to unraid, I don’t use unraid, but they cater towards a “ez straightforward” crowd so they make relatively concise and vetted info dumps):
https://forums.unraid.net/topic/102010-recommended-controllers-for-unraid/
https://forums.unraid.net/topic/41340-satasas-controllers-tested-real-world-max-throughput-during-parity-check/