Open Bug 1527710 Opened 5 years ago Updated 2 years ago

Make it possible to declare which content process subtypes can send messages in IPDL

Categories

(Core :: IPC, enhancement, P3)

enhancement

Tracking

()

Fission Milestone Future

People

(Reporter: mconley, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: sec-want)

We have a few different process types - main, content, gpu, extension... and we have several different content process "remote types": web, file://, data://, privileged.

I can see us adding more of both over time.

One of the things I can see us wanting to do in the future is putting things like about:config and about:preferences inside of the privileged content process.

This means, however, that the privileged content process will expect to be able to send a message to flip prefs - something we definitely do not want other content "remote" process types to be able to do.

It'd be excellent if we could declare in IPDL just exactly what process types can send certain messages - for example, a SetPrefs message should only ever come from a privileged content process. We can / should then probably crash any content process that attempts to send a message that doesn't fall within its type.

Handling this in the IPC layer means that the parent message handler can assume that the process that sent the message was allowed to do it, meaning we can avoid writing (or forgetting to write!) a lot of hand-rolled process type assertions in our message handlers.

Flags: needinfo?(nika)
Blocks: fission
Fission Milestone: --- → M3
Flags: needinfo?(nika)

This seems like it's more of a problem for content process subtypes than top-level IPC process types; a process that can't have a ContentChild can't send PContent messages, for example.

Priority: -- → P3
Summary: Make it possible to declare which process types can send messages in IPDL → Make it possible to declare which content process subtypes can send messages in IPDL
Fission Milestone: M3 → M4
Fission Milestone: M4 → M5
Fission Milestone: M5 → Future
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.