View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009649 | GNUnet | core service | public | 2025-03-22 18:01 | 2025-03-22 18:01 |
| Reporter | noe | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Linux x86_64 | OS | Guix | ||
| Product Version | 0.23.0 | ||||
| Summary | 0009649: gnunet-core does not report errors when connecting to the system daemon | ||||
| Description | In case of missing permissions for accessing /tmp/gnunet-system-runtime/gnunet-service-core.sock the command ”gnunet-core -s” will retry to access the socket forever without producing an error. The only way I found to know the problem was to run strace, which shows a loop of the following output: pselect6(4, [3], [], NULL, {tv_sec=4, tv_nsec=95990000}, NULL) = 0 (Timeout) socket(AF_UNIX, SOCK_STREAM, 0) = 5 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(5, {sa_family=AF_UNIX, sun_path="/tmp/gnunet-system-runtime//gnunet-service-core.sock"}, 110) = -1 EACCES (Permission non accordée) close(5) = 0 Surely it would be better to stop the loop in case of EACCES and report the error to the user instead? In this case it is the /tmp/gnunet-system-runtime directory that is created but not accessible to the current user that is not in the gnunet group, so there is no hope of getting a connection by just waiting. | ||||
| Steps To Reproduce | Run a multi-user gnunet setup and start a system daemon and a user daemon. For the user, do not have him in the “gnunet” group. gnunet-core -s will wait infinitely instead of reporting the lack of permissions. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-03-22 18:01 | noe | New Issue |
