First off, thanks very much for giving me exactly what I asked for.
You propose that instead of sometimes running ~five lines of C as root, I do one of the following:
1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in.
2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs.
3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need.
All of these alternatives tell a story:
The alternative to running ~five lines of C as root is to run *many* more lines as root.
This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root!
[0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool.
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
> What the other options allow is to contain the blast radius.
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
> With the daemon you can control access via groups on the socket...
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
> Yup! There's no way around that if in the end you need elevated privileges somewhere.
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
> 1) Run a persistent whole-ass daemon using something for IPC
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
>2)
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
>3)
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
> The fact that Linux does not have an easy to use IPC mechanism...
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
>Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
I keep trying the "native" solutions every so often, but every time I quickly hit some snag that makes me question why I'm not just using the solution that actually works. As an example, I just generated a new project using create-vite & added two subpath imports:
The second one (#/*) is similar enough to what I usually use (@/*), and it's supported in Node since v25.4.0! Yet when I try to import the file at projectRoot/src/router/index.ts using:
import router from "#/router/index"
VS Code shows an error: "Cannot find module '#/router/index' or its corresponding type declarations."
Now, imports from e.g. "#assets/main.css" work, so I could work around this issue - but this is what I keep experiencing: the native variant usually kinda works except for the most common use case, which is made unnecessarily awkward. For a long time this is what ESM used to feel like, and IMO it still does in places (e.g. directory imports not working is a shame).
To me it definitely looks like the area for the document grew. The sidebar is a solution to not tacking a million things into the toolbar, it's not like it's open 100% of the time.
You don't have to if you use mDNS. Or configure the iPhone to use your own self-hosted DNS server which can just be your router/gateway pointed to 9.9.9.9 / 1.1.1.1 / 8.8.8.8 with a few custom entries. You would need to jailbreak your iPhone to edit the hosts file.
I have a real domain name for my house. I have a few publicly available services and those are listed in public DNS. For local services, I add them to my local DNS server. For ephemeral and low importance stuff (e.g. printers) mDNS works great.
For things like Home Assistant I use the following subdomain structure, so that my password manager does the right thing:
I run similar (gitea, scrypted+ffmpeg instead of frigate, plex instead of jellyfin) plus some Minecraft servers, *arr stack, notes, dns, and my VM for development.
It's an i7-4790k from 12 years ago, it barely breaks a sweat most hours of the day.
It's not really that impressive, or (not to be a jerk) you've overestimated how expensive these services are to run.
ZFS doesn't really need huge amounts of RAM. Most of the memory usage people see is the Adaptive Replacement Cache (ARC), which will happily use as much memory as you throw at it, but will also shrink very quickly under memory pressure. ZFS really works fine with very little RAM (even less than the recommended 2GB), just with a smaller cache and thus lower performance. The only exception is if you enable deduplication, which will try to keep the entire Deduplication Table (DDT) in memory. But for most workloads, it doesn't make sense to enable that feature anyways.
That + full-disk encryption is why I went with BTRFS inside LUKS for my NAS.
They recommend 1GB RAM per 1TB storage for ZFS. Maybe they mean redundant storage, so even 2x16TB should use 16GB RAM? But it's painful enough building a NAS server when HDD prices have gone up so much lately.
The total price tag already feels like you're about to build another gaming PC rather than just a place to back up your machines and serve some videos. -_-
That said, you sure need to be educated on BTRFS to use it in fail scenarios like degraded mode. If ZFS has a better UX around that, maybe it's a better choice for most people.
1GB RAM per 1TB storage is really only required if you enable deduplication, which rarely makes sense.
Otherwise, the only benefit more RAM gets you is better performance. But it's not like ZFS performs terribly with little RAM. It's just going to more closely reflect raw disk speed, similar to other filesystems that don't do much caching.
I've run ZFS on almost all my machines for years, some with only 512MiB of RAM. It's always been rock-solid. Is more RAM better? Sure. But it's absolutely not required. Don't choose a different file system just because you think it'll perform better with little RAM. It probably won't, except under very extreme circumstances.
Also recommending using a DNS server that points `*.yourdomain` do your reverse proxy's IP. That way requests skip going outside your network and helps for ISPs that don't work with "loopback" DNS (quotes because I don't know the proper term)
You can then set your DNS in Tailscale to that machines tailnet IP and access your servers when away without having to open any ports.
And bonus, if it's pihole for dns you now get network-level Adblock both in and outside the home.
reply