"remote.enabled" is only evaluated during startup
Categories
(Remote Protocol :: Agent, defect, P5)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
Details
To turn on the remote agent the preference value from "remote.enabled" will be read. This works fine when it was set before Firefox gets started, but not when you change the value in "about:config".
I assume nothing should block us from allowing the remote agent to instantly be enabled or disabled?
Andreas, do you have any concerns?
|
||
Comment 1•5 years ago
|
||
Only the --remote-debugging-port and --remote-debugger flags
will cause the remote agent to listen for incoming connections. The
remote.enabled preference controls whether these flags are available
and blocks any attempt to make the remote agent listen when
nsIRemoteAgent.listen() is called.
In other words the behaviour of remote.enabled is different to
marionette.enabled because it doesn’t control the listener, but
the availability of the component. This is by design.
To make the remote agent listen at runtime you will have to evaluate
the following code in the browser console (with bug 1543115 applied):
Cc["@mozilla.org/remote/agent;1"].getService(Ci.nsIRemoteAgent).listen()
You can also import chrome://remote/content/RemoteAgent.jsm
and call RemoteAgent.listen().
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Andreas Tolfsen 「:ato」 from comment #1)
Only the
--remote-debugging-portand--remote-debuggerflags
will cause the remote agent to listen for incoming connections. The
remote.enabledpreference controls whether these flags are available
and blocks any attempt to make the remote agent listen when
nsIRemoteAgent.listen()is called.
Not sure I fully understand that part. When you say that remote.enabled controls if the command line flags are available what does that mean? Those flags are chosen way before the profiler manager is used to select a profile, and as such it doesn't know about the setting of this preference. For a default profile with the preference value of false those arguments are still listed on the command line.
If we don't allow to use those CLI args, we should maybe bail out. Otherwise we could save the values of those arguments and check whenever the preference remote.enabled gets changed during runtime, and enable/disable the remote agent based on its value.
To make the remote agent listen at runtime you will have to evaluate
the following code in the browser console (with bug 1543115 applied):Cc["@mozilla.org/remote/agent;1"].getService(Ci.nsIRemoteAgent).listen()You can also import
chrome://remote/content/RemoteAgent.jsm
and callRemoteAgent.listen().
And we don't want to run this automatically when the preference is turned on?
|
|
||
Comment 3•5 years ago
|
||
What I mean is that when remote.enabled is not set, the flags won’t work.
Trying to start Firefox with --remote-debugger will in that case cause an error in RemoteAgent.listen().
Think of it as a feature flag, not a control switch.
When Firefox starts shipping the remote agent this lets us control
the availability of the component to users without rebuilding Firefox.
For example if we later find we need to disable the feature due to some problem,
all we have to do is disable the feature.
By contrast, to disable Marionette you would need to recompile with --disable-marionette
and hope we got #ifdefs in all the right places and that they still work.
|
|
Reporter | |
Comment 4•5 years ago
|
||
I understand all that but what I still miss is the following part: Why do we put the Remote Agent in listen mode only during startup, but not at runtime. If the pref intentionally gets flipped it would be convenient to just put the agent in listen mode, or stop it from listening. Above you showed a workaround how this could work.
Is it an extra protection layer that no code running with chrome scope could potentially enable/disable the agent, but you have to explicitly do that with a following restart of Firefox (after flipping the pref)?
|
|
||
Comment 5•5 years ago
|
||
A single entry-point causing the agent to listen for browser-external connections
is conceptually simpler, but also reduces potential attack vectors.
It also resonates better with how (most) other *.enable feature flags in about:config work.
If we have a use case that requires starting the listener at runtime,
I would rather we developed a dedicated UI for it in about:debugging,
as we have for RDP remote debugging via USB and WLAN.
Requiring explicit user consent seems better overall
than relying on the implicitness of flipping a preference.
|
|
Reporter | |
Comment 6•5 years ago
|
||
A separate UI handling such a case would make total sense, indeed. As this is not something we can work on right now lets push this to the backlog.
|
|
Reporter | |
Comment 7•3 years ago
|
||
The remote.enabled preference has been removed by bug 1710839. As such this bug is invalid now.
Description
•