gecko-dev/dom/ipc/DocShellMessageUtils.cpp
Nika Layzell 34e62a0d9c Bug 1538028 - Part 2: Track TriggeringRemoteType through nsDocShellLoadState and LoadInfo, r=smaug,ckerschb,necko-reviewers,valentin
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.

For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.

For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:

 1. The "Triggering Process" is the process which provided the URI to load.
    This is also the process which provides the Triggering Principal. This is
    the process being tracked in this patch.

 2. The "Loading Process" is the process which actually creates the channel and
    starts the load. This may be the same as the triggering process, or may be
    a different process starting the navigation on behalf of the triggering
    process. In general this is the process hosting the current docshell,
    though it may be the parent process in the case of parent-initiated loads.

 3. The "Final Process" is the process which receives the response and renders
    the final document. This isn't known at channel creation time, and is
    determined by the result principal and process isolation policy.

This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.

The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.

Differential Revision: https://phabricator.services.mozilla.com/D161198
2022-11-29 20:41:45 +00:00

47 lines
1.6 KiB
C++

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "mozilla/dom/DocShellMessageUtils.h"
#include "mozilla/dom/DOMTypes.h"
#include "mozilla/ipc/IPDLParamTraits.h"
#include "nsSerializationHelper.h"
namespace IPC {
void ParamTraits<nsDocShellLoadState*>::Write(IPC::MessageWriter* aWriter,
nsDocShellLoadState* aParam) {
MOZ_RELEASE_ASSERT(aParam);
WriteParam(aWriter, aParam->Serialize(aWriter->GetActor()));
}
bool ParamTraits<nsDocShellLoadState*>::Read(
IPC::MessageReader* aReader, RefPtr<nsDocShellLoadState>* aResult) {
mozilla::dom::DocShellLoadStateInit loadState;
if (!ReadParam(aReader, &loadState)) {
return false;
}
// Assert if we somehow don't have a URI in our IPDL type, because we can't
// construct anything out of it. This mimics the assertion in the constructor
// for nsDocShellLoadState, but makes it clearer that the
// DocShellLoadStateInit IPC object can't be clearly converted into a
// nsDocShellLoadState.
if (!loadState.URI()) {
MOZ_ASSERT_UNREACHABLE("no URI in load state from IPC");
return false;
}
bool readSuccess = false;
RefPtr result =
new nsDocShellLoadState(loadState, aReader->GetActor(), &readSuccess);
if (readSuccess) {
*aResult = result.forget();
}
return readSuccess;
}
} // namespace IPC