Re: sysconfdir var fix

[David Suarez <oxia.eikichi () gmail com>]

El 05/09/2011 18:37, "David Fifield" <david () bamsoftware com> escribió:
> On Mon, Sep 05, 2011 at 04:01:59PM +0200, David Suarez wrote:
> > > On Thu, Sep 01, 2011 at 06:17:54PM +0200, Oxia Eikichi wrote:
> > > > Atached a patch to apply the path of (configure generated)
sysconfdir
> > > (/etc
> > > > by
> &g> On Mon, Sep 05, 2011 at 04:01:59PM +0200, David Suarez wrote:
> > > On Thu, Sep 01, 2011 at 06:17:54PM +0200, Oxia Eikichi wrote:
> > > > Atached a patch to apply the path of (configure generated) sysconfdir
> > > (/etc
> > > > by
> > > >
> > > > default) in source code. Dont sure if it is of real utility for all,
but
> > > > take
> > > >
> > > > a look. Thanks.
> >
> >
> > > Thanks, this looks like a good idea. A few things, though:
> > >
> > > For me, the default is not /etc but /usr/local/etc. I think this will
> > > cause problems.
> >
> > A mistake its /usr/local/etc, my fault, you are right.
>
> I think this is a problem that needs to be resolved. As it is, this
> patch is going to break people's installations, because while everybody
> has /etc/services, nobody has /usr/local/etc/services. We can't just do
> a global search and replace of "/etc" to "/usr/local/etc", which is what
> this patch does by default.
>
> Some options:
> 1. Set the default value of sysconfdir to /etc in configure. What are
> the consequences of this? By default everything works as before.
> Installations where people did --prefix=~/nmap or similar will still
> work, but only because we don't try to install anything to
> sysconfdir. I'm a bit concerned that this is too magical; people
> expect these installation directories to stay under prefix unless
> they say otherwise.
> 2. Make a global #define for "/etc", but don't call it SYSCONFDIR or
> any other name that by default has a value other than "/etc". This
> way it's still configurable, and we don't have to break anyone's
> expectations.
>
> Maybe the question is: What purpose are we serving by making this
> configurable? What was your initial reason for writing the patch? I can
> easily believe that there are weird Unix configurations that keep these
> files in other places, but it would be nice to have a realistic use case
> to help decide what to do next.
>
> > > Can you find a way to make it work on Windows? Windows doesn't use
> > > configure nor Makefile. Instead, I think you have to define it in
> > > nmap_winconfig.h.
> >
> > Correct me if i´m wrong... In Windows you can find "hosts", "protocol"
and
> > "services" files in "WINDOWS/system32/drivers/etc/", except for the
> > "/etc/rpc" and "/etc/resolv.conf" files that don´t have any equivalent in
> > Windows, so i dont see the point to let change the locations of this
files.
> > We could fix "nmap_services_init()", "etchosts_init()" to use a
consistent
> > method for search of this files ( the code in this two functions is
> > duplicate ) and fix "nmap_protocols_init()" to search the file there (is
> > looking for it in "/etc/protocols").
>
> I don't care about using those system32 files if we aren't already. I'm
> mainly concerned that the patch at least compiles on Windows. Otherwise
> it's more work for me or whoever else integrates it.
>
> A refactoring patch of that duplicate code is welcome.
>
> > Do you see any place in the other projects (ncat, nsock, nping, zenmap)
> > > that need such a replacement too? We should do it in all of them if we
> > > do it in any of them.
> >
> > The others projects don´t need any patch. Only libpcap need it, patch
> > attached and i will send it to upstream.
>
> Thanks for checking. I bet that the libpcap developers will have the
> same objection about the default of "/usr/local/etc", but maybe they
> have more insight into other options for working with it.
>
> You need to change these into Strncpy checks or similar, because
> SYSCONFDIR may be long:
>
> - strcpy(filename, "/etc/rpc");
> + strcpy(filename, SYSCONFDIR "/rpc");
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/