Re: [Help-gnunet] gnunet-dns interface

[Christian Grothoff]

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
> (address@hidden "/etc/gnunet.conf")
>     at disk.c:810
> #1  0xb7f56440 in GNUNET_CONFIGURATION_write (address@hidden,
>     address@hidden "/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 (address@hidden <program_main>,
> address@hidden)
>     at scheduler.c:817
> #6  0xb7f833a1 in GNUNET_PROGRAM_run2 (address@hidden,
> address@hidden,
>     address@hidden "gnunet-config [OPTIONS]",
>     address@hidden "Manipulate GNUnet
> configuration files",
>     address@hidden <options>,
> address@hidden <run>, address@hidden,
>     address@hidden) at program.c:286
> #7  0xb7f83773 in GNUNET_PROGRAM_run (argc=9, argv=0x804c658,
>     address@hidden "gnunet-config [OPTIONS]",
>     address@hidden "Manipulate GNUnet
> configuration files",
>     address@hidden <options>,
> address@hidden <run>, address@hidden)
>     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.
> 
>> address@hidden:~$ gnunet-transport -t
> 
>> passes, using a configuration file from the gnunet user's 
>> ~/.config/gnunet.conf But
> 
>> address@hidden:~$ 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
> 
>> address@hidden:~$ gnunet-setup
> 
>> with the configuration file in the gnunet user's 
>> ~/.config/gnunet.conf, when I should be running
> 
>> address@hidden:~$ 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:
> 
>> address@hidden:~$ ls -l /etc/gnunet.conf -rw-r--r-- 1 gnunet gnunet
>> 38 Feb  4 02:29 /etc/gnunet.conf
> 
>> address@hidden:~$ gnunet-setup -c /etc/gnunet.conf # zero effect on 
>> /etc/gnunet.conf address@hidden:~$ 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 address@hidden 
>> https://lists.gnu.org/mailman/listinfo/help-gnunet
> 
> 
> 
> _______________________________________________
> Help-gnunet mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-gnunet
>

signature.asc
Description: OpenPGP digital signature