[Bug libc/11558] No way to set some options in /etc/resolv.conf

[Bug libc/11558] No way to set some options in /etc/resolv.conf

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11558

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-05-30 01:44:07 UTC ---
I added a patch.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11558] No way to set some options in /etc/resolv.conf

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11558

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11558] No way to set some options in /etc/resolv.conf

[robgnubug at hagopian dot net]

------- Additional Comments From robgnubug at hagopian dot net  2010-04-30 16:59 -------
I don't have any evidence either way, but from past experiences I would suggest
that it's just as likely that there is no good reason why it is that way (e.g.,
no one thought of it/it hasn't come up before). Even though I will likely go
that route, I tend to disagree with your assessment that a preloaded object is
'eas[y]' and the fact that other settings can be changed via the options line in
/etc/resolv.conf indicates that such an object is not the solution that has been
used to date (ip6-bytestring "sets   RES_USE_BSTRING   in  _res.options";
ip6-dotint/no-ip6-dotint "Clear/set RES_NOIP6DOTINT  in  _res.options"; edns0
"sets RES_USE_EDNSO in _res.options"). The code does not appear to be completely
ancient as the last option was added around 2007.

Of course, one is always on their own when setting options that aren't defaults.
I'm not suggesting changing the defaults, only providing users [administrators]
a way to do so for at least RES_USEVC which involves adding:

                } else if (!strncmp(cp, "usevc", sizeof("usevc") - 1)) {
                        statp->options |= RES_USEVC;

Around line 541 of glibc/resolv/res_init.c

I would be happy to:
a) supply this as a patch,
b) supply a patch for all current options listed in resolv.h, or
b) if you would accept it, I would be willing to take more generic option
setting code (that takes hex arguments) from the kernel and use it here (more
future-proof but more involved and it's easier for someone to get in trouble
some day)

If you would be willing to integrate any of them.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11558

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11558] No way to set some options in /etc/resolv.conf

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-04-30 14:46 -------
The way it is how it always was.  This code is ancient and there are likely very
good reasons why it is that way.  I really have no interest to second guess
those decisions.  You can quite easily have a preloaded object for all processes
which sets the flag programmatically.  Then you're on your own and you are
responsible for the negative fallout and it's not the C library implementation's
faults.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11558

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.