After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752534 - make the portal helper use the connection-provided dns servers
make the portal helper use the connection-provided dns servers
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: portal-helper
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
triaged
Depends on:
Blocks:
 
 
Reported: 2015-07-17 14:58 UTC by Matthias Clasen
Modified: 2021-07-05 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
portal-helper: Use xdg-app to have a private view of the file system (3.85 KB, patch)
2015-09-03 15:04 UTC, Rui Matos
needs-work Details | Review
portal-helper: Ensure we use the current NM connection's DNS servers (5.59 KB, patch)
2015-09-03 15:04 UTC, Rui Matos
reviewed Details | Review

Description Matthias Clasen 2015-07-17 14:58:02 UTC
We can't rely on resolv.conf to have proper, working information before the portal login is complete. After discussing this with the dnssec-trigger team on the Fedora side, we should find a way to explictly make the portal helper use the dns servers that are specified in the connection configuration.

Two possible approaches:

1) use an LD_PRELOAD hack like https://github.com/hadess/resolvconf-override
2) set up some minimal containerization around the portal helper and bind mount a suitable resolv.conf in place
Comment 1 Tomas Hozza 2015-08-31 13:26:40 UTC
A little bit of background:

In Fedora, we plan to use Unbound as local DNS resolver together with dnssec-trigger as a tool for dynamic reconfiguration of Unbound. dnssec-trigger implements its own Captive Portal detection mechanism (fetching static HTTP site with known content), but it conflicted with NM functionality and GNOME portal helper.

Therefore we decided the disable the Captive portal detection in dnssec-trigger and also not to use dnssec-trigger panel for user interaction.

Unbound is a validating resolver and does DNSSEC validation by default. Spoofing DNS answers is considered an attack, therefore we can not configure it with the connection provided DNS resolvers before the Captive portal login happens. Thus querying 127.0.0.1 would not give the portal helper the correct answer.

Since we don't do the Captive portal detection and nm-dispatcher is not capable of notifications on Connectivity State changes we also don't know when to replace the 127.0.0.1 in resolv.conf with connection provided resolvers.

This boils down to the fact that when doing the Captive portal login, the portal helper can not really assume that the resolvers in resolv.conf are usable for name resolution (for the purpose of logging into portal). Therefore portal helper should fetch the DNS resolver IP addresses from NM via DBus API and query those directly.

NM Connectivity State currently reflects only state of the default connection, but using the connection specific DNS resolvers for portal login will enable logging into portal for non-default connections. E.g. situation when you are connected to wired network and at the same time to Wireless with Captive portal.
Comment 2 Rui Matos 2015-09-03 15:04:14 UTC
Created attachment 310604 [details] [review]
portal-helper: Use xdg-app to have a private view of the file system

In some cases we need to use different DNS servers than configured
system-wide in /etc/resolv.conf. To achieve this so that webkit uses
this particular set of DNS servers in a transparent way is to make us
run with a private view of the file system where we can control the
contents of /etc/resolv.conf without touching the system instance of
that file.

xdg-app-helper allows us to create such an environment in an easy way
without needing to be root while still sharing IPC, network and Shm
namespaces with the current user session.

If xdg-app-helper isn't in PATH at runtime, we transparently fall back
to run just as we did before.
Comment 3 Rui Matos 2015-09-03 15:04:22 UTC
Created attachment 310605 [details] [review]
portal-helper: Ensure we use the current NM connection's DNS servers

On systems with a local DNS resolver doing DNSSEC validation we aren't
able to resolve names using the system DNS configuration in
/etc/resolv.conf since that just points to the local resolver which
refuses any requests until the user logs in through the portal and our
host gets a working route to the internet.

If we are running in a sandbox where we can write to a private
instance of /etc/resolv.conf, we can use the DNS servers provided by
the network administrator and made available to us by NetworkManager,
for own process only and thus be able to resolve names so that we can
load the portal.
Comment 4 Tomas Hozza 2015-11-19 08:40:00 UTC
(In reply to Rui Matos from comment #3)

Hi Rui.

Thank you for all your work. Is there any estimate on when these changes will be included in the Gnome release?

Thank you.
Comment 5 Bastien Nocera 2017-01-18 16:39:03 UTC
Review of attachment 310604 [details] [review]:

xdg-app-helper doesn't exist anymore. This needs porting to bubblewrap.
Comment 6 Bastien Nocera 2017-01-18 16:41:21 UTC
Review of attachment 310605 [details] [review]:

The approach looks correct, but I wonder whether we should also make sure that the traffic only ever goes through the interface which we're trying to configure, rather than "the default gateway".
Comment 7 Bastien Nocera 2017-01-18 16:42:24 UTC
(In reply to Bastien Nocera from comment #5)
> Review of attachment 310604 [details] [review] [review]:
> 
> xdg-app-helper doesn't exist anymore. This needs porting to bubblewrap.

Which might also solve bug 769692, if we don't have access to GSettings to read the proxy settings (?).
Comment 8 Tomas Hozza 2017-01-24 13:10:18 UTC
(In reply to Bastien Nocera from comment #6)
> Review of attachment 310605 [details] [review] [review]:
> 
> The approach looks correct, but I wonder whether we should also make sure
> that the traffic only ever goes through the interface which we're trying to
> configure, rather than "the default gateway".

Hello Bastien and thank you for reviewing this bug.

As I mentioned at the bottom of comment #1, the usual situation will be that the captive portal is on the default connection (marked as such by NM) and therefore the connection will be used as the default route for network communication.

Nevertheless things in NM might change since 2015 in a way that NM is able to report the captive portal also for non-default connections.

In my opinion a more generic solution would be to make sure that when doing captive portal login, the communication goes through the interface that is being configured (and from which DNS resolvers are used by the portal helper).
Comment 9 Bastien Nocera 2017-02-13 11:46:59 UTC
Review of attachment 310604 [details] [review]:

::: src/gnome-shell-portal-helper.c
@@ +66,3 @@
+      return TRUE;
+
+  return FALSE;

This needs to report FALSE if on non-Linux or bwrap isn't available.

@@ +80,3 @@
+    app_helper_path,
+    "-f", "-g", "-i", "-n", "-s",
+    "-b", "/etc/pki=/etc/pki",  /* webkit needs this */

"-f", // Mount the host filesystems read-only
    "-g", // Allow use of direct rendering graphics
    "-i", // Share IPC namespace with session
    "-n", // Share network namespace with session
    "-s", // Share Shm namespace with session
    "-b", "/etc/pki=/etc/pki",  /* webkit needs this */ // Bind extra source path read-only into DEST
     "/usr" // run-time path

I documented the arguments, to make it easier to port to bwrap.

I'd also note that the helper is very specific. Maybe an additional flag could be passed so we can change the args if we were to use it for something else, or it needs a more specific name.
Comment 10 Tomas Hozza 2018-07-12 08:45:21 UTC
Hi.

Is there any update or progress on this issue?
Comment 11 Bastien Nocera 2018-07-13 08:20:15 UTC
(In reply to Tomas Hozza from comment #10)
> Hi.
> 
> Is there any update or progress on this issue?

It's waiting for someone to provide an updated patch.
Comment 12 GNOME Infrastructure Team 2021-07-05 14:27:07 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.