RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 689424 - [RFE] Use reserved port only when required
Summary: [RFE] Use reserved port only when required
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.0
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Jeff Law
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
: 729349 (view as bug list)
Depends On:
Blocks: 607248 689425 756082 782183
TreeView+ depends on / blocked
 
Reported: 2011-03-21 13:41 UTC by J.H.M. Dassen (Ray)
Modified: 2018-12-01 19:01 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 689425 (view as bug list)
Environment:
Last Closed: 2013-04-24 14:36:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 729349 0 unspecified CLOSED all reserved ports in use 2021-02-22 00:41:40 UTC

Internal Links: 729349

Description J.H.M. Dassen (Ray) 2011-03-21 13:41:36 UTC
2. What is the nature and description of the request?

- use non-reserved source ports for non-secure NIS map lookups.
- use reserved ports fort secure maps

   3. Why does the customer need this?:

When customer rcp a lots of small files via rcp from their supercomputer to
RHEL, it fails sometimes and found that it happened when reserved ports get
exhausted by NIS clients. So they are proposing this solution so that not use
reserved potrs for all NIS lookup (indeed by root user) but use reserved ports
only for secure NIS map lookups and use non-reserved ports for other lookups.

   4. How would the customer like to achieve this? :

They are looking something like as HP implemented
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02037757/c02037757.pdf

"Reduced Usage of Reserved Ports
Reserved ports are the ports from 0 to 1024. Only root users can bind to these
ports. In previous releases, NIS commands attempted to bind to reserved ports
by default. If there are numerous client requests, all the reserved ports can
be consumed. This version of NIS enables binding to reserved ports for select
commands or daemons when accessing secure maps which results in reduced usage
of reserved ports by NIS. This change does not compromise performance or
security. "

   5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Run tcpdump and verify source ports for NIS lookup.

   6. Is there already an existing RFE upstream or in Red Hat bugzilla?

No

   7. How quickly does this need resolved?

RHEL 5 minor release

   8. Does this request meet the RHEL Inclusion criteria?

Yes

   9. List the affected packages:

ypbind

  10. Would the customer be able to assist in testing this functionality if
implemented?:

Yes

Comment 5 J.H.M. Dassen (Ray) 2011-06-24 10:33:18 UTC
Sachin, Engineering still requires answers to their questions in comment #2; please work with the customer to obtain them.

Comment 6 RHEL Program Management 2011-07-06 01:14:54 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 12 pgregg 2011-10-25 00:27:13 UTC
Also interested in an update, plus details of an official workaround from RH. This particular issue is affecting our RHEL 6.1 Certification process.

Per standard RHEL 6.1 install, we lose rsh/rlogin connectivity after 7 rsh calls.

Flipping nsswitch.conf hosts order to place nis after dns, changes the number to 40 rsh calls before loss of service.

Comment 13 Jeff Law 2012-02-17 19:11:29 UTC
*** Bug 729349 has been marked as a duplicate of this bug. ***

Comment 16 pgregg 2012-08-02 11:22:39 UTC
I can't see comment #2 however, this issue remains, unupdated, more than a year after the report.
(after each test - I wait for TIME_WAIT sockets to drop to zero)

Default RHEL config (nsswitch.conf with hosts: files nis dns)
# T=sunv40z-17
# for a in {1..100}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
+++++++---------------------------------------------------------------------------------------------

Flipping dns and nis order:
# for a in {1..100}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------

[root@sunv40z-17 pam.d]# netstat -na | grep TIME_WAIT | wc -l
1241

Remove nis from hosts: entry in nsswitch.conf - I get to around 100 or 101 successes before it stops responding:

#for a in {1..150}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------

Please advise if I need to raise the severity through our partner liason.

Comment 17 Paul Hinchman 2012-08-02 16:16:07 UTC
Red Hat, We need updates to this ASAP.

R/

Paul Hinchman
Linux Storage Connectivity Program Mgr.
Hewlett-Packard

Also adding Steve Almy and Chris Tatman

Comment 18 Matt Newsome 2012-08-03 16:54:07 UTC
Just a courtesy update to acknowledge the request from the Red Hat engineering side. We'll have a look at this afresh and see if we can give you some conclusive feedback shortly. Thanks for your patience.

Comment 21 Jeff Law 2012-08-10 02:33:25 UTC
Honza,

I doubt the glibc maintainers will accept that patch as-is, at least not without you or someone with explicit knowledge of this issue championing it.  I simply don't know this code, nor YP and all the issues surrounding it at all -- so if I were to try to champion it, well, all I could do is continually refer back to you or someone else with better knowledge of this issue.

The obvious issues I'd expect them to raise will be around security, ie, what are the implications of not using a reserved port?

Comment 22 Honza Horak 2012-08-10 13:28:04 UTC
So I posted an initial message to glibc maintainers with a slightly enhanced patch (use environment variable to define which maps are secure and use current behaviour in case the variable is not set). Feel free to join discussion:
http://sourceware.org/ml/libc-alpha/2012-08/msg00170.html

Comment 23 Honza Horak 2012-08-13 10:37:22 UTC
Paul or anyone else, can we get some more info, please, how this feature is implemented on the client side by HP? Particularly, how secured maps are defined on the client side? Is there any configuration file/variable or is ypbind's yp.conf used for that?

Comment 24 Siddharth Nagar 2013-04-24 14:36:51 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of Red Hat Enterprise Linux. If you would like Red Hat to re-consider your feature request, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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