View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005782 | GNUnet | GNS | public | 2019-06-27 00:48 | 2020-07-09 09:17 |
| Reporter | rockxo | Assigned To | schanzen | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.11.5 | ||||
| Target Version | 0.13.0 | Fixed in Version | 0.13.0 | ||
| Summary | 0005782: Activated gns plugin never returns with stopped GNUnet | ||||
| Description | When 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 Reproduce | Install 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, …) | ||||
| Tags | No tags attached. | ||||
|
|
We should probably add a timeout option to gnunet-gns and use that in the nsswitch plugin |
|
|
Attempted fix in e0698f82e..92a2b1758. Can you test? |
|
|
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? |
|
|
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). |
|
|
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. |
|
|
@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. |
|
|
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? |
|
|
"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 |
|
|
"1." In the above comment is currently broken or requires "2." which we should avoid. |
|
|
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. |
|
|
> 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? |
|
|
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. |
|
|
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 |
|
|
0.13.0 released |
| 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 |
|
Issue cloned: 0006290 | |
| 2020-06-01 00:52 |
|
Issue cloned: 0006333 | |
| 2020-07-09 09:17 | schanzen | Note Added: 0016418 | |
| 2020-07-09 09:17 | schanzen | Status | resolved => closed |
