You are not logged in.
I am the maintainer of the gnunet package on AUR. Recently there has been an upstream update and I have taken the opportunity for doing a general revision of my package.
I believe at this point the AUR package is in a very good state. But although the service seems to work, I am not able to make the file sharing module function properly (the gnunet-search command hangs idefinitely). I wonder at this point whether it is an upstream problem or I did something wrong with my files (the current revision at the moment of writing this post is here).
Both the installation and the usage of GNUnet are very well documented in the website, and I believe I have followed the guide scrupulously.
Is there anyone who wants to give a fast look to my package on AUR and try to understand where the problem is?
Last edited by grufo (2021-08-23 01:39:55)
Offline
Was the issue present with the old PKGBUILD / version?
Why when you were updating the PKGBUILD did you use a .install file instead of creating the user and group using sysusers and fixing up permissions using tmpfiles.d?
adjusting the upstream provided tmpfiles conf?
Also .install files should never remove users / groups.
Last edited by loqs (2021-08-19 21:51:07)
Offline
@loqs
Thank you for your reply.
Was the issue present with the old PKGBUILD / version?
That is a good question. I have adopted the package only recently, and in general I have tested gnunet's file sharing when it was in the official repositories and always as root, and it worked as such. Now it does not work if launched both as root and as normal user.
Why when you were updating the PKGBUILD did you use a .install file instead of adjusting the upstream provided tmpfiles conf?
Also .install files should never remove users / groups.
If you look at the README file, under “Notes on setuid”, you can see that user and groups need to be present at the time the gnunet.install script is launched.
Offline
I would suggest it is an upstream issue or upstream change. You could also try downgrading the package and see if the older version still works.
If you look at the README file, under “Notes on setuid”, you can see that user and groups need to be present at the time the gnunet.install script is launched.
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-vpn
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-vpn
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-transport-wlan
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-transport-wlan
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-transport-bluetooth
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-transport-bluetooth
chown root $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chmod 4750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chown gnunet:$(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chmod 2750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-exit
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-exit
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-nat-server
chown root:root $(DESTDIR)$(libexecdir)/gnunet-helper-nat-client
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-nat-server
chmod u+s $(DESTDIR)$(libexecdir)/gnunet-helper-nat-client
All of the above be accomplished by tmpfiles which will be run after sysusershas been run so the user and groups will exist.
Something like:
z /usr/lib/gnunet/gnunet-helper-dns 2750 gnunet gnunetdns
z /usr/lib/gnunet/libexec/gnunet-helper-exit 4750 root root
z /usr/lib/gnunet/libexec/gnunet-helper-nat-server 4750 root root
z /usr/lib/gnunet/libexec/gnunet-helper-nat-client 4750 root root
The following confused me
chown root $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chmod 4750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chown gnunet:$(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
chmod 2750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns
I am parsing it as:
set ownership root:root for $(DESTDIR)$(libexecdir)/gnunet-helper-dns,
set group root $(DESTDIR)$(libexecdir)/gnunet-helper-dns,
set mode 4750 (setuid) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set group gnunetdns $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set owner gnunet:gnunetdns $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set mode 2750 (setgid) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
The last two lines result in the four previous lines settings being pointless with an end result of mode 2750 (setgid) ownership gnunet:gnunetdns.
Edit:
Are the settings from gnunet.html#Access-Control-for-GNUnet out of date / wrong with respect to gnunet-helper-dns?
Last edited by loqs (2021-08-20 03:57:28)
Offline
@loqs
Thank you again for the follow-up.
I would suggest it is an upstream issue or upstream change. You could also try downgrading the package and see if the older version still works.
That is a good suggestion. But I am not sure I will have time to check the previous documentation and downgrade the PKGBUILD properly.
All of the above be accomplished by tmpfiles which will be run after sysusershas been run so the user and groups will exist.
That is a great suggestion. I have updated the AUR package now.
The following confused me
chown root $(DESTDIR)$(libexecdir)/gnunet-helper-dns chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns chmod 4750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns chgrp $(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns chown gnunet:$(GNUNETDNS_GROUP) $(DESTDIR)$(libexecdir)/gnunet-helper-dns chmod 2750 $(DESTDIR)$(libexecdir)/gnunet-helper-dns
I am parsing it as:
set ownership root:root for $(DESTDIR)$(libexecdir)/gnunet-helper-dns,
set group root $(DESTDIR)$(libexecdir)/gnunet-helper-dns,
set mode 4750 (setuid) $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set group gnunetdns $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set owner gnunet:gnunetdns $(DESTDIR)$(libexecdir)/gnunet-helper-dns
set mode 2750 (setgid) $(DESTDIR)$(libexecdir)/gnunet-helper-dnsThe last two lines result in the four previous lines settings being pointless with an end result of mode 2750 (setgid) ownership gnunet:gnunetdns.
Yes, the last two lines are a bit odd indeed, but apparently you translated them well in your tmpfiles.
Edit:
Are the settings from gnunet.html#Access-Control-for-GNUnet out of date / wrong with respect to gnunet-helper-dns?
I guess no? What makes you wonder if they are?
EDIT:
@loqs Would you like to be a co-maintainer of the gnunet package on AUR?
Last edited by grufo (2021-08-20 14:12:46)
Offline
https://docs.gnunet.org/handbook/gnunet … etdns_0022
A special group "gnunetdns" should be created for controlling access to the "gnunet-helper-dns". The binary should then be owned by root and be in group "gnunetdns" and be installed SUID and only be group-executable (2750).
That would set the ownership of gnunet-helper-dns root:gnunetdns rather than gnunet:gnunetdns. 2750 mode matches but that is SGID not SUID.
Note that the group "gnunetdns" should have no users in it at all, ever.
Done
The "gnunet-service-dns" program should be executed by user "gnunet" (via gnunet-service-arm) with the binary owned by the user "root" and the group "gnunetdns" and be SGID (2700).
Not done? gnunet-service-arm is not covered by the install script / tmpfiles.d.
Thank you for the co-maintainer offer. However I do not want to maintain any packages I do not regularly use.
Offline
@loqs
That would set the ownership of gnunet-helper-dns root:gnunetdns rather than gnunet:gnunetdns. 2750 mode matches but that is SGID not SUID.
I have tried all the combinations but no results. My question was about the file sharing service, but even focusing on the core service it should be possible ideally to run gnunet-peerinfo after starting the daemon as user "gnunet" by launching:
sudo -u gnunet gnunet-arm -s
gnunet-peerinfo
or, equivalently,
sudo systemctl start gnunet
gnunet-peerinfo
In both cases gnunet-peerinfo hangs indefinitely. The gnunet-peerinfo command works fine instead if gnunet-arm -s is launched as normal user:
gnunet-arm -s
gnunet-peerinfo
I suspect that the problem in this case lies in some wrong setuid/setgid.
Not done? gnunet-service-arm is not covered by the install script / tmpfiles.d.
That is another good point.
Thank you for the co-maintainer offer. However I do not want to maintain any packages I do not regularly use.
You are welcome. But if you find any solution, please do share it.
Offline
I might have solved the issue. It seems there was a problem with the configuration file distributed by the AUR package (/etc/gnunet.conf) which was a relic from very old versions of GNUnet.
After updating it I can now launch
sudo systemctl start gnunet
gnunet-search 'the'
and get some dozens of results (it might take a bit before the results show up).
I have now also updated the GNUnet article in the wiki.
@loqs
Would you please make a test and confirm that the new version of the gnunet package (or, equivalently, the git version gnunet-git) works for you?
Please make sure to remove the old /etc/gnunet.conf file and that your user is added to the gnunet group before trying.
Last edited by grufo (2021-08-22 17:11:50)
Offline
Initally gnunet.service failed /var/lib/gnunet was not created. Adding the follwing to gnunet.tmpfiles
d /var/lib/gnunet 0700 gnunet gnunet - -
to create it fixed that issue. You could instead use StateDirectory=gnunet in the service file.
gnunet-search 'the'
Provided no output
gnunet-search 'commons'
Provided matches. Possibly the is too short / generic?
Edit:
Oh, should the package's license be AGPL3 instead of MIT? See the COPYING file in the source bundle.
Last edited by loqs (2021-08-22 19:53:01)
Offline
Initally gnunet.service failed /var/lib/gnunet was not created. Adding the follwing to gnunet.tmpfiles
d /var/lib/gnunet 0700 gnunet gnunet - -
to create it fixed that issue.
Good catch! Fixed.
You could instead use StateDirectory=gnunet in the service file.
Your contributions are always precious. Added StateDirectory=gnunet to the service file.
gnunet-search 'the'
Provided no output
gnunet-search 'commons'
Provided matches. Possibly the is too short / generic?
The new network (v0.15.0) is small, as it is incompatible with people who still run previous versions of GNUnet, and my concern is not so much about how many files can be found; the important thing is that at least something can be found – that means that the package is OK.
Edit:
Oh, should the package's license be AGPL3 instead of MIT? See the COPYING file in the source bundle.
The licence in the AUR package was GPL, but as a you currently point out it should be AGPL3. Fixed this as well.
Thank you a lot, loqs. We can safely assume now that Arch has the best distribution of GNUnet among all GNU/Linux distributions.
EDIT:
If you have time please check the diff of my last edits.
Differently than you, instead of adding a line, I have replaced
Z /var/lib/gnunet 0700 gnunet gnunet - -
with
d /var/lib/gnunet 0700 gnunet gnunet - -
in gnunet.tmpfiles.
Last edited by grufo (2021-08-22 21:37:54)
Offline