1401656 - Investigate how moz-extension URI's use the System Principal in content process

Status: NEW

(WebExtensions :: Request Handling, enhancement, P3)

Description

[Haik Aftandilian [:haik]]

Working on bug 1377355, I found that in content processes, moz-extension URI's are loaded using the System principal. That was not expected by reviewers and it was requested I file a bug to track investigating whether or not that is correct. The question is should moz-extension URI's use the SystemPrincipal in the child process?

Comment 1

[Andy McKay]

Sounds like this is a request for information, marking as a P3 for now though.

Comment 2

[Shane Caraveo (:mixedpuppy)]

I looks like it's the loadingprincipal that is the system principal.  Content scripts are loaded, compiled and cached, then when needed, injected into a sandbox that is attached to the content frame.  I suspect it is fine that the loading principal in this case is system, I'm not sure how it could be otherwise, but lets get a second opinion from Kris.

Comment 3

[Kris Maglione [:kmag]]

They are definitely not loaded using the system principal.

Comment 4

[Haik Aftandilian [:haik]]

Specifically, we had this code in the parent process which was checking the |aChildLoadInfo| sent over from the child for a load of a resource from an unpacked webextension. GetLoadingPrincipal() returned the system principal and the IsSystemPrincipal() check returned true causing the load to fail. The fix for bug 1377355 was to remove the check, allowing the use of the system principle to create the file channel for load. This caused concern with the reviewers.

Old code:

  ...
  nsCOMPtr<nsIPrincipal> childPrincipal;
  NS_TRY(aChildLoadInfo->GetLoadingPrincipal(getter_AddRefs(childPrincipal)));
  if (nsContentUtils::IsSystemPrincipal(childPrincipal)) {
    return Err(NS_ERROR_FILE_ACCESS_DENIED);
  }
  ...

The |aChildLoadInfo| came from the nsILoadInfo argument passed to ExtensionProtocolHandler::SubstituteChannel() in the child process. The code has changed since then and now the child process doesn't provide a LoadInfo to the parent for this case. Now, in the parent process we have the following use of the system principal.

ExtensionProtocolHandler.cpp : ExtensionProtocolHandler::NewStream()
   ...
   689   // We use the system principal to get a file channel for the request,         
   690   // but only after we've checked (above) that the child URI is of              
   691   // moz-extension scheme and that the URI host maps to a directory.            
   692   nsCOMPtr<nsIChannel> channel;                                                 
   693   MOZ_TRY(NS_NewChannel(getter_AddRefs(channel),                                
   694                         resolvedURI,                                            
   695                         nsContentUtils::GetSystemPrincipal(),                   
   696                         nsILoadInfo::SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,       
   697                         nsIContentPolicy::TYPE_OTHER));

We need a principal that permits loads from arbitrary locations on the filesystem because unpacked extensions can be stored anywhere on the filesystem. Therefore, I think we must either use the system principal or an "expanded principal" that would just include the file system or better yet just the directory containing the unpacked extension.