Hi Calvin, You are right, there is no good reason for GNUnet to need any additional privs on /etc/. I must admit I mostly use it with ~/.config/gnunet.conf, or some other non-default configuration file passed via "-c", so I never encountered this particular issue.
We should probably just open the *existing* file rw and then truncate instead of creating a new file. So yes, this is another (minor) bug that should be fixed. I've filed it as bug #3653 so that it is not forgotten: https://gnunet.org/bugs/view.php?id=3653 Also, btw, I'm myself not ignoring your previous e-mail, I'm currently working intensely on that connectivity issue which clearly wasn't nearly as well under control as I had first thought... Happy hacking! Christian On 02/05/2015 11:57 AM, Calvin Heim wrote: > Hi Christian, > > So... gnunet-config hasn't been writing to /etc/gnunet.conf on my > machine. I think this has been happening because I only gave the > gnunet user write permissions for /etc/gnunet.conf. But I think I need > to give write permissions for the whole directory of /etc/ because > there's a call to access() to check the user's write permissions for > /etc/ when the command > > gnunet-config -c /etc/gnunet.conf > > runs. Here's the relevant line and backtrace from gdb: > > 810 if ((ret == GNUNET_OK) && (0 != ACCESS (rdir, W_OK))) > (gdb) p rdir > $1 = 0x8053c68 "/etc" > (gdb) bt > #0 GNUNET_DISK_directory_create_for_file > (filename=filename@entry=0x8053c50 "/etc/gnunet.conf") > at disk.c:810 > #1 0xb7f56440 in GNUNET_CONFIGURATION_write (cfg=cfg@entry=0x804d420, > filename=filename@entry=0x804d1c8 "/etc/gnunet.conf") at > configuration.c:487 > #2 0x08048ada in run (cls=0x0, args=0x804c67c, cfgfile=0x804d1c8 > "/etc/gnunet.conf", cfg=0x804c710) > at gnunet-config.c:140 > #3 0xb7f82bf0 in program_main (cls=0xbffffaa0, tc=0xbffffa24) at > program.c:84 > #4 0xb7f8979d in run_ready (ws=<optimized out>, rs=<optimized out>) > at scheduler.c:595 > #5 GNUNET_SCHEDULER_run (task=task@entry=0xb7f82ba0 <program_main>, > task_cls=task_cls@entry=0xbffffaa0) > at scheduler.c:817 > #6 0xb7f833a1 in GNUNET_PROGRAM_run2 (argc=argc@entry=9, > argv=argv@entry=0x804c658, > binaryName=binaryName@entry=0x8048cd8 "gnunet-config [OPTIONS]", > binaryHelp=binaryHelp@entry=0x8048dc8 "Manipulate GNUnet > configuration files", > options=options@entry=0x8048e40 <options>, > task=task@entry=0x8048a70 <run>, task_cls=task_cls@entry=0x0, > run_without_scheduler=run_without_scheduler@entry=0) at program.c:286 > #7 0xb7f83773 in GNUNET_PROGRAM_run (argc=9, argv=0x804c658, > binaryName=binaryName@entry=0x8048cd8 "gnunet-config [OPTIONS]", > binaryHelp=binaryHelp@entry=0x8048dc8 "Manipulate GNUnet > configuration files", > options=options@entry=0x8048e40 <options>, > task=task@entry=0x8048a70 <run>, task_cls=task_cls@entry=0x0) > at program.c:325 > #8 0x08048901 in main (argc=9, argv=0x804c658) at gnunet-config.c:177 > > So, this might be a dumb question, but does gnunet write other files > to /etc/ besides the configuration file? In other words, why does the > gnunet user need write permissions for /etc/ beyond the configuration > file? > > Calvin > On 02/04/2015 02:55 AM, Calvin Heim wrote: >> Hi Christian, > >> I was mistaken when I said that the transport tests were passing >> -- they aren't passing. I misunderstood what was being tested. > >> gnunet@Compy:~$ gnunet-transport -t > >> passes, using a configuration file from the gnunet user's >> ~/.config/gnunet.conf But > >> gnunet@Compy:~$ gnunet-transport -t -c /etc/gnunet.conf > >> does *not* pass because setup changes aren't being written to >> /etc/gnunet.conf. I've been (mistakenly?) running > >> gnunet@Compy:~$ gnunet-setup > >> with the configuration file in the gnunet user's >> ~/.config/gnunet.conf, when I should be running > >> gnunet@Compy:~$ gnunet-setup -c /etc/gnunet.conf > >> instead. However, I've been unable to write to /etc/gnunet.conf >> through either gnunet-config or gnunet-setup, despite gnunet >> owning the file and being able to write to it via text editor. I am >> perplexed as to why I can't save changes, even when the permissions >> seem right: > >> gnunet@Compy:~$ ls -l /etc/gnunet.conf -rw-r--r-- 1 gnunet gnunet >> 38 Feb 4 02:29 /etc/gnunet.conf > >> gnunet@Compy:~$ gnunet-setup -c /etc/gnunet.conf # zero effect on >> /etc/gnunet.conf gnunet@Compy:~$ vim /etc/gnunet.conf # >> successfully writes to file > >> On 01/27/2015 05:03 AM, Christian Grothoff wrote: >>> Things seem to be much better now, and I've restarted the peer >>> at gnunet.org with a version that does connect again (it had >>> been running a 'broken' version for a few days, which might have >>> prevented new peers from bootstrapping, even if they ran an >>> working version). AFAIK SVN HEAD should also connect fine with >>> 0.10.1 (but I didn't test it explicitly). So trying now should >>> work better. -Christian > > >> _______________________________________________ Help-gnunet mailing >> list [email protected] >> https://lists.gnu.org/mailman/listinfo/help-gnunet > > > > _______________________________________________ > Help-gnunet mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/help-gnunet >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help-gnunet mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnunet
