| Summary: | Don't use in-tree BSD getopt implementation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Nick Jones <nick.jones> | ||||
| Component: | openssh | Assignee: | Jan F. Chadima <jchadima> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.0 | CC: | jrieden | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-04-21 11:28:08 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
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? 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. can I close this BZ in hope that the patch I'll get via upstream? Yes, please close. Upstream is a better place to propose this. |
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.