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 1784172 - slapi-nis malfuction when group length is more than 1024 characters
Summary: slapi-nis malfuction when group length is more than 1024 characters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: slapi-nis
Version: 8.1
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Alexander Bokovoy
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-16 21:55 UTC by toasty
Modified: 2023-03-24 16:28 UTC (History)
7 users (show)

Fixed In Version: slapi-nis-0.60.0-1.module+el8.7.0+16405+581a7c1e
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-08 09:35:45 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-7188 0 None None None 2021-10-29 13:13:12 UTC
Red Hat Issue Tracker RHELPLAN-31186 0 None None None 2021-10-29 13:13:10 UTC
Red Hat Product Errata RHBA-2022:7540 0 None None None 2022-11-08 09:36:23 UTC

Description toasty 2019-12-16 21:55:37 UTC 
Description of problem: slapi-nis malfuction when group length is more than 1024 characters

Version-Release number of selected component (if applicable):
rhel7.6
slapi-nis-0.56.0-8.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. create group 'thisgroup' in ipa
2. add members until 'ypcat group|grep thisgroup' has length > 1024
3. do an 'ls -l' on a dir with group ownership by 'thisgroup'

Actual results:
1. gid showed as number
2. newgrp 'thisgroup' requires password
3. access to dirs with thisgroup as groupwoners fails
4. nis clients get 'do_ypcall: clnt_call: RPC: Remote system error' error on the NIS client]' error [fails]

Expected results:
1. groupowner showed as name
2. newgrp should not ask password
3. access to dirs with thisgroup as groupwoners 
4. no do_ypcall errors on nis clients

Additional info: 
See '/usr/share/doc/slapi-nis-0.56.0/nis-configuration.txt' :

"* nis-max-dgram-size
   This sets the maximum size of a response that the server will attempt
   to send to clients which issued a query over UDP.  The default value
   is 1024 bytes."

Raising the value to 8192 results in the NIS client responding properly.
Comment 2 Alexander Bokovoy 2019-12-17 09:29:07 UTC 
Current behaviour is intended and documented. 

I think to solve this bug it would be either to implement dynamic backoff to increase the response size or to set higher defaults.
Since there is a clear workaround by modifying a server side configuration, I'm moving this bug to RHEL 8.
Comment 6 Theodoros Apazoglou 2022-02-01 11:01:26 UTC 
Moving this task to 8.7 due to high workload and no time left for dev work on 8.6.
Comment 12 Trivino 2022-07-27 10:18:38 UTC 
Shifting DTM/ITM by one more week.
Comment 14 Alexander Bokovoy 2022-08-20 06:31:30 UTC 
Thinking more about it.

By default, max datagram record size in NIS protocol is limited to
YPMAXRECORD which is 1024 bytes. However, in 2013 glibc allowed to
change this value up to 16MB in runtime and FreeBSD followed the trend
in 2019 (https://reviews.freebsd.org/D20900). These changes allow NIS
servers to send buffers of any sizes up to 16MB if clients allocate
their memory in heap.

There is still one place where YPMAXRECORD is used for a stack 
allocation in glibc: xdr_ypall() function. Access to individual
keys/values can use up to 16MB of memory but through xdr_ypall() the
buffers to store individual record key/value pairs is limited to
YPMAXRECORD size on stack. It means if a server has sent a larger
key/value pair, a client stack could still be smashed.

For slapi-nis, there is no easy way of knowing in advance the size of
the record to be sent. Large groups can easily get beyond default 1024
bytes. There is a NIS plugin setting (nis-max-dgram-size) that can be
used to adjust configuration.

Let's use 8KB as a default for now. NIS support is going to be phased
out, Fedora and RHEL 9 already removed NIS client side code.
Comment 20 errata-xmlrpc 2022-11-08 09:35:45 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (idm:client and idm:DL1 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7540
Note You need to log in before you can comment on or make changes to this bug.