4 ms·

Plan9 gets a lot of this right. The author should flesh out why "Unix is bad".

by bakul 3y ago

Ericson2314 3y ago
Plan 9 made a number of improvements, but while "everything is a file" is an improvement, "everything is a file descriptor" think is better. namespaces aside, files as global variables, while file descriptors are local variables. It is much more easy to make an interface that "naturally" makes it easy to abide by https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege with local variables. Unix < Plan 9 < Capiscum-like designs, for me. (Of course, if Capsicum is "capability-based security for Unix", maybe a "capability-based security for Plan 9" is better than that. :))
- bakul 3y ago
  Plan9 in fact uses file descriptors all over the place, including accessing synthetic or real filesystems (which are really namespaces). In fact the only "globals" are the #<dev> devices. IMHO you're better off starting with plan9 concepts + pure capabilities (KeyKOS as opposed to Capsicum). It would not enough to have a clean architecture unless a) it matches or improves upon performance and b) there is a way to run existing Unix software via some adapter layer or library or monitor. I suspect if you try to "reform" unix, there will be a lot of recidivism :-)
  - ksjskskskkk 3y ago
    capros. keykos is so 1980. i miss when osnews was still decent.
  - Ericson2314 3y ago
    > recidivism Yes, it is not enough to just add yet more interfaces. Using personalities to ban the use of deprecated systemcalls is an essential follow-up step. Fostering experimental kennels which don't bother to support the old interfaces at all is another.
- nrr 3y ago
  Funnily enough, Plan 9 implements a kind of proto-capability security environment given how namespaces work. You have to squint a bit at it, but the semantics are mostly there. Of particular note, the maxim "you can't attack what you can't see" is reasonably well represented. Whenever you rfork() a new process, you can shed whatever parts of the new namespace are irrelevant before ultimately exec()ing, and barring certain exceptions, the new image running in that child process can't get them back on its own. There are ways to augment other namespaces with mounts that are reminiscent of delegating a capability to another process. There are also ways to lock down a process to prevent it from changing its namespace, which is roughly congruent to blocking a process from receiving delegated capabilities.
- Findecanor 3y ago
  I think Capsicum is a good start, but it does not have revocation built in — which I think is essential for a system in which capabilities can be held by long-lived apps or services. There are approaches where revocation is expressed as a network of capabilities, but that just makes using it more complex. Also, revocation should be cascading: revoking also derived capabilities. The system would need to store a delegation-tree. Then there's the issue processor time for cascading revocation, which could depend on the size of the tree.
  - Ericson2314 3y ago
    Yes that would be good, but I'm OK delaying it. People are used to capabilities without revocation from functional programming, Rust, WASI, etc., and don't mind so much in that context. (Well, weak references allow revocation, but they are relatively rare.) Yes, interprocess vs intraprocess is different, but the above makes me at least think there is some juice and first exposing the lower-hanging fruit that people are already familiar with and seem to like, and then using the success of that to motivate/fund revocation.
IshKebab 3y ago
Keep reading. The entire article is a list of reasons why Unix is bad (and suggestions for how to fix it).
sph 3y ago
Not the author but I recommend: "What UNIX cost us" by Benno Rice: https://youtu.be/9-IWMbJXoLM?si=3c0YkPtfAJHWB_Q- https://youtu.be/9-IWMbJXoLM?si=3c0YkPtfAJHWB_Q- In fact, this video argues that file descriptors are not as good as the author claims in their opening paragraph. They are another runaway idiosyncrasy borne out of the "everything is a file (but not really)" philosophy that underpins Linux.

Plan9 gets a lot of this right. The author should flesh out why "Unix is bad".

by bakul 3y ago

Plan9 gets a lot of this right. The author should flesh out why "Unix is bad".

Plan 9 made a number of improvements, but while "everything is a file" is an improvement, "everything is a file descriptor" think is better. namespaces aside, files as global variables, while file descriptors are local variables. It is much more easy to make an interface that "naturally" makes it easy to abide by https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege with local variables. Unix < Plan 9 < Capiscum-like designs, for me. (Of course, if Capsicum is "capability-based security for Unix", maybe a "capability-based security for Plan 9" is better than that. :))

bakul 3y ago
Plan9 in fact uses file descriptors all over the place, including accessing synthetic or real filesystems (which are really namespaces). In fact the only "globals" are the #<dev> devices. IMHO you're better off starting with plan9 concepts + pure capabilities (KeyKOS as opposed to Capsicum). It would not enough to have a clean architecture unless a) it matches or improves upon performance and b) there is a way to run existing Unix software via some adapter layer or library or monitor. I suspect if you try to "reform" unix, there will be a lot of recidivism :-)
- ksjskskskkk 3y ago
  capros. keykos is so 1980. i miss when osnews was still decent.
- Ericson2314 3y ago
  > recidivism Yes, it is not enough to just add yet more interfaces. Using personalities to ban the use of deprecated systemcalls is an essential follow-up step. Fostering experimental kennels which don't bother to support the old interfaces at all is another.
nrr 3y ago
Funnily enough, Plan 9 implements a kind of proto-capability security environment given how namespaces work. You have to squint a bit at it, but the semantics are mostly there. Of particular note, the maxim "you can't attack what you can't see" is reasonably well represented. Whenever you rfork() a new process, you can shed whatever parts of the new namespace are irrelevant before ultimately exec()ing, and barring certain exceptions, the new image running in that child process can't get them back on its own. There are ways to augment other namespaces with mounts that are reminiscent of delegating a capability to another process. There are also ways to lock down a process to prevent it from changing its namespace, which is roughly congruent to blocking a process from receiving delegated capabilities.
Findecanor 3y ago
I think Capsicum is a good start, but it does not have revocation built in — which I think is essential for a system in which capabilities can be held by long-lived apps or services. There are approaches where revocation is expressed as a network of capabilities, but that just makes using it more complex. Also, revocation should be cascading: revoking also derived capabilities. The system would need to store a delegation-tree. Then there's the issue processor time for cascading revocation, which could depend on the size of the tree.
- Ericson2314 3y ago
  Yes that would be good, but I'm OK delaying it. People are used to capabilities without revocation from functional programming, Rust, WASI, etc., and don't mind so much in that context. (Well, weak references allow revocation, but they are relatively rare.) Yes, interprocess vs intraprocess is different, but the above makes me at least think there is some juice and first exposing the lower-hanging fruit that people are already familiar with and seem to like, and then using the success of that to motivate/fund revocation.

IshKebab 3y ago

Keep reading. The entire article is a list of reasons why Unix is bad (and suggestions for how to fix it).

sph 3y ago

Not the author but I recommend: "What UNIX cost us" by Benno Rice: https://youtu.be/9-IWMbJXoLM?si=3c0YkPtfAJHWB_Q- https://youtu.be/9-IWMbJXoLM?si=3c0YkPtfAJHWB_Q- In fact, this video argues that file descriptors are not as good as the author claims in their opening paragraph. They are another runaway idiosyncrasy borne out of the "everything is a file (but not really)" philosophy that underpins Linux.