Bug 584802 - groups are not correctly updated when /etc/group /etc/gshadow are modified
Summary: groups are not correctly updated when /etc/group /etc/gshadow are modified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-22 13:04 UTC by ilja lunev
Modified: 2011-07-21 12:18 UTC (History)
2 users (show)

Fixed In Version: coreutils-5.97-28.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-21 10:36:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1074 0 normal SHIPPED_LIVE coreutils bug fix and enhancement update 2011-07-21 10:33:32 UTC

Description ilja lunev 2010-04-22 13:04:15 UTC
Description of problem:
If a user is added to a group by editing /etc/group and /etc/gshadow the system does not correctly accept this.
If  groups {login} is  run afterwards it still shows the groups before the edit.
This is especially a problem if a user is added to a samba group references in /etc/samba/shares.conf.
Such a user can not access the share although he/she is correctly shown in /etc/group and /etc/gshadow.
If a grpck command is run then the group change is correctly shown and samba access is possible.

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


How reproducible:


Steps to Reproduce:
1.   vigr         # add user UserX to group GroupY
2.   group UserX  # does not show list GroupY
3.   grpck
4.   group UserX  # GroupY is correctly shown
  
Actual results:


Expected results:


Additional info:

Comment 1 ilja lunev 2010-04-22 13:16:33 UTC
If the command groupmod is used the groups are updated correctly.
There is no written evidence though that editing the group file is not sufficient.
It is especially difficult to track samba access problems down if the files and even system-config-user shows the groups correctly.
The problem does not exist on Red Hat Enterprise Linux WS release 3 (Taroon Update 9) nor on Red Hat Enterprise Linux WS release 4 (Nahant Update 3).

Comment 2 Ondrej Vasik 2010-04-22 13:48:26 UTC
Thanks for report, however, thats expected and not a bug.

Following information was added into groups info documentation by http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=167b8025aca487de001da2448c1aebc2747bc1d3:
"Primary and supplementary groups for a process are normally inherited
from its parent and are usually unchanged since login.  This means that
if you change the group database after logging in, `groups' will not
reflect your changes within your existing login session.  Running
`groups' with a list of users causes the user and group database to be
consulted afresh, and so will give a different result."

So maybe just documentation should be tweaked a bit.

Comment 3 Ondrej Vasik 2010-04-22 13:52:13 UTC
However - that part about RHEL-3/4 is interesting ... as in RHEL-5 groups is just shell script above id command, I'll check a bit what changed there... 
However the comment with information that changes within existing login session are not reflected without refreshed user/group database is valid.

Comment 4 ilja lunev 2010-04-27 12:16:50 UTC
I understand the effect on the current login session.
The real problem is that samba access does not work properly as before.
Example:
 A user asks me for a share access on a server.
 I add the user to /etc/passwd, shadow, group and gshadow (with a custom script I have for that).
 I also add the user to a group shareXusers.
 In /etc/samba/shares.conf share access is referenced like  "write list = @shareXusers" 
 The I ask the user to test access.
 Before the latest update on RHel5 this was no problem and it still is no problem on RHel3, RHel4 and Ubuntu.
 Since the latest update of RHel5 about 4 weeks ago the share access is denied until I issue a grpck or a similar command.

Comment 5 Ondrej Vasik 2010-04-27 12:48:17 UTC
So RHEL-5.3/4 had no such problem and it occured after update to RHEL-5.5? Strange - there was no such change in RHEL-5.5 coreutils (no coreutils update in fact) - last coreutils update was 5.4 - and no change related to id or groups was included.
As all those utilities depends on systemcalls, maybe some change in kernel was done. I don't know - if you have some machine with working RHEL-5 and not working RHEL-5, could you please check the change in `strace id -Gn <user>`?

Additionally - please contact www.redhat.com/support if you want to have more investigation of the issue - RH bugzilla is just bugtracker, not support tool. They may have more time to investigate the issue and probably search for the culprit of the change in behaviour.

Comment 7 RHEL Program Management 2010-08-09 18:18:20 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.

Comment 10 RHEL Program Management 2011-01-11 20:15:15 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.

Comment 11 RHEL Program Management 2011-01-11 22:23:02 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 16 errata-xmlrpc 2011-07-21 10:36:35 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1074.html

Comment 17 errata-xmlrpc 2011-07-21 12:18:17 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1074.html


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