Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you're going to have capability-based security, please be louder and prouder about it.



The book's subtitle is literally "A modular, capability-based operating system"[1]

[1]: https://fuchsia.googlesource.com/docs/+/master/book.md


Judging by nomenclature it seems to be more influenced by Plan 9, which also adhered somewhat to capability-based security without advertising that fact.


Maybe. They start with names. However, the description looks more like access control lists than what I saw in KeyKOS, LOCK, EROS, E, or Combex's work.


> An empty process has nothing > Namespaces are the gateway to the world

Sounds like capability security to me. Although I wish they had said more about how these namespaces work. If they are inheritable and you can virtualize them for child processes (as you can in Plan 9/Inferno) then I'd say it qualifies.


When you create a child process, you can clone your namespace or you can construct a new one for the child.

(Disclosure: I wrote the doc linked above.)


Thanks. How about virtualization? Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications? Can a process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?


> Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications?

Yes. When creating the namespace for the child, the parent can map names to what whatever communication channels it chooses. If the parent wants to interpose on the child's access to "/dev/class/framebuffer", the parent could map that name to a channel that leads back to the parent.

> Can a process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?

Yes. That's useful for testing as well as for sandboxing.


Thank you for taking the time to reply, despite the sea of low quality comments on this HN thread.


Appreciate your your answers. This makes Fuchsia quite interesting to me.


Someone told me there were ex-devs of QNX microkernel doing Google's. Is that true?


Not sure about QNX, but the lead developers are ex Be, Danger, Palm and Apple.


Thanks for that clarification. That is an interesting mix.


As for QNX, one of its founders, Dan Dodge, is now at Apple.


In Unix, rights - even POSIX "cpabilities" - belong to the process. In Magenta, the rights are attached to the handle.


They can't be louder and prouder about it, because they know at one point they'll have to compromise it so that Google own apps can track the user.


Oh damn, you broke the triple secret NDA. Next people will find out that Fuchsia is the color faces need to get before the project is revealed to be a conspiracy theory generator.

There are plenty of important reasons for this project, that plenty of people in the past have already made note of. If the one you're going for, already, is some ad/user tracking platform, you're purposely attempting to narrow the capability of your thinking.

(Disclosure: Google employee disappointed that Hacker News doesn't save the eye-roll emoji.)


Sorry, I wasn't aware there's triple secret NDA on the fact that Google's main business is advertising...


Conspiratorial or not - on Google platforms, 3rd party applications are 2nd class citizens. Do you think an outside party could write Open-WIFI given the present service integration policies?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: