Re: [Help-gnunet] a few more questions on GNUnet operation

[Christian Grothoff]

On 10/21/2012 08:42 AM, Ivan Shmakov wrote:
>         A bunch of questions I've got after running a few GNUnet nodes,
>         for a few days, which, I hope, will be answered here.  TIA.
>
>         • Unless topology/FRIENDS-ONLY is set to YES, what the ‘friends’
>           list is used for?  Is it used to specify the preferred peers
>           to which the connections are established?

https://gnunet.org/configuration-f2f

>         • gnunet-peerinfo(1) lists some 27 peers on a couple of
>           dual-stacke nodes.  Is it normal?

Yes, most likely.

>         • What are the meanings of CHK (content hash key?), SKS, KSK,
>           Loc (location)?  What's their syntax and semantics?

https://gnunet.org/fs-urisyntax

>         • Are, for instance, the “content hash” and “query hash” parts
>           of an CHK URI base32hex-encoded SHA-512 values?

Yes.

>         • But what is the meaning of “query hash”?  Is it a hash over
>           the metadata?  If so, does such metadata include further
>           piece-wise (or block-wise) hashes of the content?  Are such
>           pieces fixed-length (nearly 64 KiB?) octet sequences?

Query hash does not go over meta data.

>         • Is it possible to search for identifiers under a known
>           namespace?

Yes, that's what 'sks' URIs specify: a search for identifiers under a 
known namespace.

>         • Where are the implemented --meta= keys are listed?

$ extract -L # from GNU libextractor

>         • It seems that gnunet-pseudonym(1) blocks SIGINT, SIGTERM, and
>           SIGQUIT.  Why?

All GNUnet processes do that; they trap the signal and then shut down. 
However, gnunet-pseudonym may currently be unable to do so as it can be 
stuck (in GNUnet 0.9.3) creating an RSA-key in libgcrypt, which does not 
allow us to gracefully stop its key generation process.

>         • I've published a file on node A a couple of days ago, and it's
>           now shown among the gnunet-serach(1) results on node B, but
>           not on node C.  What could've gone wrong?

No idea.  We have a few interesting bugs in SVN HEAD, and as some nodes 
are running that version, some peers are really misbehaving right now, 
which may interfere with routing.

>         • There's the transport/DISABLEV6 option to disable the use of
>           IPv6.  Is there a complementary DISABLEV4 one?  (One of my
>           nodes is IPv4-firewalled against “The World”, so I'd rather
>           disable the use of IPv4 on it altogether.)  Is it generally
>           possible to set the addresses (or interfaces) the node will
>           listen at?

Use the "BINDTO" option.  There is no DISABLEV4 (feel free to send a 
patch --- nobody ever asked for this one yet...).

>         • A number of binaries (as per the gnunet-server 0.9.3-2 Debian
>           package) come set-UID root:
>
> gnunet-helper-dns
> gnunet-helper-exit
> gnunet-helper-fs-publish
> gnunet-helper-nat-client
> gnunet-helper-nat-server
> gnunet-helper-transport-wlan
> gnunet-helper-vpn

Ugh, gnunet-helper-fs-publish should NOT be SUID!  That's a serious bug 
in the Debian package, please report it to Debian!

>           While I understand that such privileges are necessary for
>           certain operations (like the creation of TUN/TAP devices),
>           this raises security concerns, and also (in the case of
>           gnunet-helper-fs-publish) has practical implications for a
>           particular use case.  (Not to mention that it's generally
>           possible to pre-create a TUN/TAP device and grant access to it
>           to a particular user.)  How these set-UID binaries are used,
>           and what'd be the consequences of dropping set-UID from them?

With the exception of gnunet-helper-fs-publish, they will simply not 
work if they are not SUID.  They all create virtual interfaces (and 
sometimes do other "nasty" stuff) which requires root.  These binaries 
are all VERY simple C code (almost linear), do not link against any 
libraries other than GNU libc and we are always looking for people do a 
security audit on these in particular.  Note that gnunet-helper-dns must 
not be executable by 'normal' users, only by the special 'gnunet' user. 
 See also https://gnunet.org/gnunet-access-control-model

Happy hacking!

Christian