Bug 188015 - Including individual NIS groups in /etc/group does not work
Summary: Including individual NIS groups in /etc/group does not work
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ypbind   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
Depends On:
Blocks: 176344
TreeView+ depends on / blocked
Reported: 2006-04-05 12:29 UTC by Timo Ruiter
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-08 19:00:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Timo Ruiter 2006-04-05 12:29:30 UTC
Description of problem:

It seems not to be possible to include individual NIS group entries in
/etc/group (using +<group>:::) without also including all other NIS groups
(using +::: at the end of the file).  This way of including (or excluding)
entries *does* work for /etc/passwd.
When running 'ls -l /home' (with a 'user private group' policy active, so
directories are owned by groups corresponding to the individual users) the
output only lists the group ID's, not the group names when the +::: entry is
missing.  The user names are displayed correctly, though.
Running 'strace ls -l /home' shows that the nscd socket is queried for group
names (or the NIS server if nscd is not running) if the +::: is added; these
queries are missing entirely (and no other system calls are made instead) if the
+::: entry is missing.

Version-Release number of selected component (if applicable):

How reproducible:
Correct output of 'ls -l /home' when +::: entry is present (group names).
Incorrect output of 'ls -l /home' when +::: entry is missing (group ID's only).

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Steve Dickson 2006-07-20 12:30:22 UTC
I believe this to be a glibc issue since that were the code 
that does the password parsing lives... Now the question I have 
is did the Linux NIS version ever support this type of functionality?

Comment 2 Timo Ruiter 2006-07-21 20:31:51 UTC
It may well have done so, but I don't know. Maybe it didn't, but frankly, I
don't care.  Although the manpages and other docs don't state it explicitly,
including a single group using +group::: should give you just the one group,
instead of no group at all.  The whole mechanism can be abolished if the only
way to make inclusion of a group work is to include all other groups afterwards
as well... The only use for this type of behaviour is to exclude a group out of
the whole set of groups (with -group:::, but didn't checked that), but that is
no viable option, since the set of groups changes constantly. And if you want to
exclude all but some groups, you're in for a lot of work...!

Comment 3 Timo Ruiter 2006-07-31 21:18:03 UTC
Although I would find it couter-intuitive and rather crude, I would accept it if
inclusion of single groups works if a line with
is added as the last line of /etc/group, having the meaning "include all groups,
but select none of them..."
Since I have no access to a system to test this right now I leave this comment
as a hint.

Comment 5 RHEL Product and Program Management 2006-08-18 16:19:05 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 7 RHEL Product and Program Management 2006-09-08 19:00:11 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

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