Oh god yes please. If pledge() makes it into the mainline kernel, we OpenBSD-type people seem less weird when submitting patches for some syscall "nobody uses".
Many OpenBSD ports contain pledge() support. Steal all you can. OpenBSD does "hoisting" in many userland programs, meaning all the open calls and such take place at the very start but isn't actually parsed until after we have locked ourselves in with pledge() and unveil(). I hope this also means many non-base programs are redesigned in this manner.
I too would love pledge() in Linux. But as I pretty much implied in this comment thread (https://news.ycombinator.com/item?id=32097649) the project here won't get us there, and it does need to be part of the kernel.
Of course the problem is that it needs some cooperation between libc and the kernel. That's why it's easier for OpenBSD to provide it.
> Of course the problem is that it needs some cooperation between libc and the kernel.
You may have missed that our new pledge() impl is hosted in the Cosmopolitan Libc repository. So we've got cooperation. Therefore it'd help to clarify when you say this project won't get us there, that you're only speaking for glibc. pledge.com works fine with everything else like Musl and Cosmo Libc. It even works with glibc most of the time. One can't reasonably expect cosmo to need to support glibc before being able to support itself. We've learned today that folks want this. So the Glibc dev team should be doing more to help us. What I fear is that they're focused on different things.
If it were just that then porting it to Linux would not have taken this long. OpenBSD were able to copy things from Linux (e.g. some grsecurity/PAX stuff), and vice versa. But in this case the org model is getting in the way.
OpenBSD is able to provide these things because they have a different organizational model.
Or to put another way: Linux is shipping the org chart.
OpenBSD can do some other interesting things because they don't have the mantra of "we don't break user space". Neither is wrong, just different. High level strategies like these affect commercial success and also the abilities to ship technical solutions.
Or on the topic of the article here: Yes, if you replace libc, restrict to just one arch, and put many other restrictions on userspace, then under those circumstances your only "opponent" is the kernel, and you can implement something partially like pledge().
But really, that means that you solve the multiparty problem by kicking out everyone who's in your way, who you can't get rid of (namely the kernel).
Many OpenBSD ports contain pledge() support. Steal all you can. OpenBSD does "hoisting" in many userland programs, meaning all the open calls and such take place at the very start but isn't actually parsed until after we have locked ourselves in with pledge() and unveil(). I hope this also means many non-base programs are redesigned in this manner.