View Issue Details

IDProjectCategoryView StatusLast Update
0005782GNUnetGNSpublic2020-07-09 09:17
Reporterrockxo Assigned Toschanzen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.11.5 
Target Version0.13.0Fixed in Version0.13.0 
Summary0005782: Activated gns plugin never returns with stopped GNUnet
DescriptionWhen nsswitch is configured to use gns prior to dns, but GNUnet is not running at all, it will wait forever and block a DNS request that comes from a application like ping or wget.
Steps To ReproduceInstall GNUnet (do not start it)
Follow docs.gnunet.org, section 4.5 “Installation”:
Copy libnss_gns.so* into system-wide lib dir
Modify /etc/nsswitch.conf to activate the plugin

-> Try any non-browser activity that requires DNS resolving (ping, wget, …)
TagsNo tags attached.

Activities

schanzen

2019-06-27 08:40

administrator   ~0014604

We should probably add a timeout option to gnunet-gns and use that in the nsswitch plugin

schanzen

2019-06-27 09:09

administrator   ~0014605

Attempted fix in e0698f82e..92a2b1758. Can you test?

rockxo

2019-06-27 21:23

reporter   ~0014606

Fixes the forever-blocking.
Now it fails after 10 seconds with:
“No address associated with hostname”

However, when docs recommends
<quote>
Add the text "gns [NOTFOUND=return]" after "files".
</quote>
it still fails, due to the NOTFOUND=return.

Did you consider checking for the presence of a GNUnet instance at this point?

schanzen

2019-06-27 21:39

administrator   ~0014607

I see. The problem is that we cannot distinguish between GNUnet not running and GNS not providing a reply in the lookup.
Both results in a timeout.
In the GNS API we actually first check if the TLD used in the domain _can_ be found in GNS, but the last step in this check requires the identity service -> hangs if GNUnet not running. (identity_api_suffix_lookup.c)

When GNS times out and it is/was a GNS name, we want to return "NOTFOUND" to nss.
However, if GNUnet is not running, we actually want to return "UNAVAIL" so that NSS continues with DNS.
Not sure how we can fix that without a hack (e.g. first checking if we can iterate over Egos).

schanzen

2019-06-27 21:40

administrator   ~0014608

As far as I remember, GNS had a timeout in the API a long time ago. If we could distinguish between that timeout and a timeout in the gnunet-gns CLI we could address this.
But that would require a significant change in GNS and its API.

schanzen

2019-06-27 21:47

administrator   ~0014609

Last edited: 2019-06-27 22:02

@grothoff: Maybe we can add an identity function that _only_ checks if the TLD is available as ego without querying the service?
The egos are key files anyway, right?
Of course, this would fail if the service is running somewhere wehere we do not have access to those files. Which is theoretically possible.
Then, we would be left only with the option above.

Christian Grothoff

2019-06-29 10:46

manager   ~0014616

Well, the issue with "just access the files directly" is that rexxnor pointed out that deleting an ego today doesn't delete the associated zone (which is a UX issue).
Moreover, we're currently *duplicating* the private keys in the Namestore database.

So really, we should eventually fuse (!) namestore and identity and have both use the *same* database (and drop the zone if the respective ego is deleted, i.e. via CASCADE on DELETE).
Plus the API needs to be changed to properly support transactions, so quite a bit of work on that front in the future, which makes the "just bypass identity" hack not really working.

The real issue is that we have a confidentiality/availability trade-off here: if we just fall back to DNS whenever GNUnet is not running, we might expose sensitive GNS names to DNS; but if we block DNS because GNUnet is not running, we're creating a serious availability issue. One thing we could _consider_ is to detect that GNUnet is not running and auto-launch GNUnet. What do you think of this option?

schanzen

2019-06-29 15:11

administrator   ~0014617

"The real issue is that we have a confidentiality/availability trade-off here: if we just fall back to DNS whenever GNUnet is not running, we might expose sensitive GNS names to DNS; but if we block DNS because GNUnet is not running, we're creating a serious availability issue. "

That is the issue I was trying to explain. This is why we need functionality to determine if GNS should be queried for a name. This check must work
_without_ the need of a running gnunet instance.
Then, the nss plugin can return the correct code which will hand the request over to DNS (or other subsystems) or stop the resolution correctly.

This worked before because we knew ".gnu" was GNS's only namespace. Now it is more complicated, but we still need to address it.
This issue shows us that we cannot just break nsswitch like that. We must be able to correctly do the following when receiving a request through NSS:

1. Check if GNS is authoritative for this name
-> If not, return -2 => continue in nss with next plugin
-> If yes, continue
2. Check if GNUnet is running
-> If not, return -3 (NOTFOUND) (Here you could implement an autostart)
-> If yes, continue
3. Query GNS
-> If timeout, return -3
-> If found, return result

schanzen

2019-06-29 15:13

administrator   ~0014618

"1." In the above comment is currently broken or requires "2." which we should avoid.

Christian Grothoff

2019-06-30 16:39

manager   ~0014619

Well, checking if GNS is authoritative means talking to identity (or in the future possibly namestore). I don't like the idea of just breaking the existing encapsulation of the state apart and implementing a "mini" version of idenity/namestore in gnunet-gns. Which is why I propose to just launch GNUnet in this case. Note that this would be the per-user instance, not the per-host peer instance (if the system is configured for the split-mode). Which means we _only_ learn if GNS is applicable, but wouldn't actually launch network activities.

dvn

2019-09-06 21:08

developer   ~0014872

> Which is why I propose to just launch GNUnet in this case. Note that this would be the per-user instance, not the per-host peer instance (if the system is configured for the split-mode). Which means we _only_ learn if GNS is applicable, but wouldn't actually launch network activities.

This idea seems fair. What about explicitly only launching the services needed for GNS and Identity?

schanzen

2019-09-06 23:19

administrator   ~0014873

Three problems I have with that:

1. gnunet-arm -i gns will also hang if gnunet is not (yet) running which means we need to somehow detect if it is already running and then otherwise start gnunet (first).
2. We do not know if that how gnunet should be/can be run on that system if it is not running (per user / system service etc).
3. What do we do if the connection between gnunet-gns and the service is not working as expected? It will hang as well. So we might need a timeout in either case where we do not know if that is because gns is still resolving or it is just broken.

schanzen

2020-05-10 00:30

administrator   ~0015874

Fix in 2cd529519..44bdb66b4
The behaviour now is:
- Try resolution with gnunet-gns
- If it fails because arm is not running, try to start ARM and try again
- If it fails because of a timeout and ARM is running -> Service unavailable
- If it fails because name is not in GNS -> try next plugin
- If name not found -> NOTFOUND

schanzen

2020-07-09 09:17

administrator   ~0016418

0.13.0 released

Issue History

Date Modified Username Field Change
2019-06-27 00:48 rockxo New Issue
2019-06-27 08:40 schanzen Note Added: 0014604
2019-06-27 08:40 schanzen Assigned To => schanzen
2019-06-27 08:40 schanzen Status new => assigned
2019-06-27 09:09 schanzen Status assigned => feedback
2019-06-27 09:09 schanzen Note Added: 0014605
2019-06-27 21:23 rockxo Note Added: 0014606
2019-06-27 21:23 rockxo Status feedback => assigned
2019-06-27 21:39 schanzen Note Added: 0014607
2019-06-27 21:39 schanzen Assigned To schanzen => Christian Grothoff
2019-06-27 21:40 schanzen Status assigned => feedback
2019-06-27 21:40 schanzen Note Added: 0014608
2019-06-27 21:47 schanzen Note Added: 0014609
2019-06-27 21:48 schanzen Note Edited: 0014609
2019-06-27 21:54 schanzen Note Edited: 0014609
2019-06-27 22:02 schanzen Note Edited: 0014609
2019-06-29 10:46 Christian Grothoff Note Added: 0014616
2019-06-29 15:11 schanzen Note Added: 0014617
2019-06-29 15:13 schanzen Note Added: 0014618
2019-06-30 16:39 Christian Grothoff Note Added: 0014619
2019-08-08 19:13 schanzen Target Version => 0.11.7
2019-08-08 19:14 schanzen Assigned To Christian Grothoff => schanzen
2019-09-06 21:08 dvn Note Added: 0014872
2019-09-06 23:19 schanzen Note Added: 0014873
2019-10-27 19:26 schanzen Target Version 0.11.7 => 0.11.8
2019-11-04 23:05 schanzen Target Version 0.11.8 => 0.11.9
2019-11-08 11:25 schanzen Status feedback => confirmed
2020-04-24 10:34 schanzen Target Version => 0.13.0
2020-05-10 00:30 schanzen Status confirmed => resolved
2020-05-10 00:30 schanzen Resolution open => fixed
2020-05-10 00:30 schanzen Fixed in Version => 0.13.0
2020-05-10 00:30 schanzen Note Added: 0015874
2020-06-01 00:49 Adminknox Issue cloned: 0006290
2020-06-01 00:52 Adminknox Issue cloned: 0006333
2020-07-09 09:17 schanzen Note Added: 0016418
2020-07-09 09:17 schanzen Status resolved => closed