RPC failure on NIS operation

Bug #1181275 reported by Trevor Robinson
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Starting with 13.04, NIS fails when parsing long group lines (in my case, 1262 bytes).

On login, errors such as the following are repeated numerous times:

yp_all: clnt_call: RPC: Can't decode result
do_ypcall: clnt_call: RPC: Can't decode result

The root cause can be seen with ypcat, where the first long group line causes a failure:

$ ypcat group.byname
<shorter lines printed correctly>
yp_all: clnt_call: RPC: Can't decode result
No such map group.byname. Reason: RPC failure on NIS operation

Perhaps this is due to a security fix similar to this one in RHEL, where YP record parsing was limited to YPMAXRECORD (1024):

https://bugzilla.redhat.com/show_bug.cgi?id=848748

The regression this caused was reported and fixed for Fedora 18:

https://bugzilla.redhat.com/show_bug.cgi?id=892777
https://admin.fedoraproject.org/updates/glibc-2.16-31.fc18
http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130429/1008442.html

As mentioned in that bug report, NIS entries are technically limited to 1024 characters, but Linux has not historically enforced this. A workaround is to break long group entries into separate lines with slightly different names but the same GID:

http://www.linux-nis.org/nis-howto/HOWTO/maps.html#AEN548

description: updated
Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Triaged: Identified discussions elsewhere and apparent fix
Medium: hmm it's fairly importnat but then according to the other links you're breaking spec by going over 1024

Changed in eglibc (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Lenin (gagarin) wrote :

Same problem here, works fine with 12.04, however 13.04 just misses lines > 1024 bytes:
ypcat group |awk '{print length, $0}' |sort -n

Revision history for this message
Michael Meier (michael-meier-rrze) wrote :

Please fix this very annoying and completely needless regression before the next LTS release.
Yes, the initial NIS spec said the limit was 1024 bytes. But all Linux clients have had the limit set at 64 KB instead since forever. The server still does. It does not make sense to suddenly break clients for no reason at all, especially considering this is an old protocol mostly used in legacy deployments.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.