4 ms·

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. So you've red

by epoch1970 11y ago

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. So you've rediscovered what UNIX has allowed us to do for decades now. Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then. Best of all, this functionality was offered without needing to resort to resource-intensive virtual machines or anything of that sort. Those who want the level of isolation you propose have been able to get it for a long time now. They just tend not to, because it's inconvenient and impractical for real world systems.

marssaxman 11y ago
Oh, sure, but once you start playing "there's nothing new under the sun", the mainframe guys will eventually come along and explain how they were doing all that in some vastly more sophisticated way back in 1962 using systems none of us have ever heard of. So what? I don't care. I just think that the definition of "practical" is shifting, and I want to play with another way of doing things in case it turns out to suit my needs better.
wbl 11y ago
That's just not true. A program needs to be started root to execute setuid(2): there is no way for a program started by an unprivileged user to drop privileges. Nor can it drop network privileges. That's why tools like pledge(2) and seccomp had to be added, but they have their own problems. To get the level of isolation GP described, you need some fairly esoteric solutions.
- ploxiln 11y ago
  Well seccomp() strict mode (only allows read, write, exit) has been available since linux-2.6.12 (2005). So no need to invent something new, or set up a bunch of cgroups and namespaces, to get processes that can only read stdin and write stdout and use some of their own memory.

marssaxman 11y ago

Oh, sure, but once you start playing "there's nothing new under the sun", the mainframe guys will eventually come along and explain how they were doing all that in some vastly more sophisticated way back in 1962 using systems none of us have ever heard of. So what? I don't care. I just think that the definition of "practical" is shifting, and I want to play with another way of doing things in case it turns out to suit my needs better.

wbl 11y ago

That's just not true. A program needs to be started root to execute setuid(2): there is no way for a program started by an unprivileged user to drop privileges. Nor can it drop network privileges. That's why tools like pledge(2) and seccomp had to be added, but they have their own problems. To get the level of isolation GP described, you need some fairly esoteric solutions.

ploxiln 11y ago
Well seccomp() strict mode (only allows read, write, exit) has been available since linux-2.6.12 (2005). So no need to invent something new, or set up a bunch of cgroups and namespaces, to get processes that can only read stdin and write stdout and use some of their own memory.