Bug 696569 - Don't use in-tree BSD getopt implementation
Summary: Don't use in-tree BSD getopt implementation
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.0
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Jan F. Chadima
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-14 10:33 UTC by Nick Jones
Modified: 2011-04-21 11:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-21 11:28:08 UTC
Target Upstream Version:


Attachments (Terms of Use)
Allow linux to use its own getopt (3.58 KB, patch)
2011-04-14 10:33 UTC, Nick Jones
no flags Details | Diff

Description Nick Jones 2011-04-14 10:33:30 UTC
Created attachment 492025 [details]
Allow linux to use its own getopt

Description of problem:
If one wishes to use getopt_long in the ssh program, then one is confronted with issues because openssh uses an in-tree implementation of getopt based on the BSD implementation.


Version-Release number of selected component (if applicable):
openssh-5.3p1-20.el6_0.3.x86_64


How reproducible:
Always after making a trivial (at face value) conversion to getopt_long

Steps to Reproduce:
Setting up the appropriate variables including struct option list of a single { 0, 0, 0, 0 } element, and the required index variables, then calling getopt_long instead of getopt.  None of the parameters can receive the optarg string


Actual results:
Even existing command line params that expect arguments are presented with an optarg value that is always NULL, the same goes for long options


Expected results:
optarg is not NULL, existing params receive their arguments as with getopt


Additional info:
This patch was motivated by an internal change I was making to add a custom command line flag to the ssh client.  Seeing as many single character flags are used already, I decided to use a long option to make it distinct and lessen chances of conflicts with common releases of openssh.

During openssh configure, the host system is queried for the existence of an exported variable 'optreset', which is present in the BSD c library, but not in glibc.  If not found, as it is in linux, openssh then goes an aliases the getopt function and it's associated exported variables with those found in an in-tree BSD compat implementation of getopt using C macros, this alternative implementation of getopt provides optreset.

The alternative BSD getopt provides... getopt, but it doesn't provide getopt_long, so when one invokes that, they are getting the glibc version, which treats the exported variables differently to BSD, and hilarity ensues.

My patch addressing the issue doesn't try to use getopt_long, it just allows linux to use the glibc getopt, and the glibc (and other non-BSD C libraries) method of resetting the getopt parse.  It sets the stage for one to use getopt_long if they wish.

I hope somebody can find this useful.

Comment 2 Jan F. Chadima 2011-04-14 16:35:18 UTC
Did you consult the patch with the upstream? What is the upstream meaning? Have any reference to the mindrot bugzilla or openssh-devel mail list with the discussion?

Comment 3 Nick Jones 2011-04-20 04:35:40 UTC
You are right, I should consult upstream about this.

In addition, I think a better alternative would be to add getopt_long implementation to the in-tree BSD solution, rather than create more linkages with the external environment.  Openssh is a ported project after all, and not initially developed for Linux.

Comment 4 Jan F. Chadima 2011-04-20 12:24:27 UTC
can I close this BZ in hope that the patch I'll get via upstream?

Comment 5 Nick Jones 2011-04-21 03:52:50 UTC
Yes, please close.  Upstream is a better place to propose this.


Note You need to log in before you can comment on or make changes to this bug.