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 1727236 - usermod fails to report failure while adding local user to network group
Summary: usermod fails to report failure while adding local user to network group
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: shadow-utils
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: ---
Assignee: Iker Pedrosa
QA Contact: sssd-qe
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-05 07:03 UTC by Arpit Tolani
Modified: 2023-12-15 16:36 UTC (History)
8 users (show)

Fixed In Version: shadow-utils-4.6-10.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:42:09 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4467 0 None None None 2020-11-04 01:42:14 UTC

Description Arpit Tolani 2019-07-05 07:03:16 UTC 
Description of problem:
usermod fails to report failure while adding local user to network group.


Version-Release number of selected component (if applicable):
shadow-utils-4.6-7.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Add a local user & network group.
2. Try to make user member of that group.

# getent passwd -s files casetest
casetest:x:1000:1000::/home/casetest:/bin/bash

# getent group -s sss admins
admins:*:661000000:admin

# id casetest
uid=1000(casetest) gid=1000(casetest) groups=1000(casetest)

# usermod -G admins casetest

# id casetest
uid=1000(casetest) gid=1000(casetest) groups=1000(casetest)


Additional info:
It is expected to fail, as adding secondary group for a user require modification in group entry which is not possible as group is added on LDAP server. 

But above command should fail with valid error code, right now it is returning 0.

# usermod -G admins casetest
# echo $?
0
Comment 1 Tomas Mraz 2019-07-08 16:02:33 UTC 
This would require adding a check whether any of the groups listed in the -G option is non-local. Currently the code goes through all local groups and if it finds matching one in -G it will do the modification. So that basically means the non-local groups are currently completely ignored.

Should be done upstream first.
Comment 2 Simo Sorce 2019-10-01 18:53:19 UTC 
This bug is incorrectly defined.

With the merge group option in nsswitch.conf you can have members of a group defined both in the local database and the network database.

So it is incorrect to refuse to add a user to agroup just based on the provenance of the group.

The merge option need also to be considered in this case and a local group may be created if the merge option is present.
Comment 3 Tomas Mraz 2019-10-02 07:25:37 UTC 
Creating a local group if merge option is enabled would be a RFE.

Reporting error properly would be a bug fix, anyway this is for upstream and I do not plan to work on this one any time soon.
Comment 13 Iker Pedrosa 2020-05-05 09:58:50 UTC 
* master
    f929bfd90b3a469fae4494da243e1a9e0fbdf9d5 - Check only local groups when adding new supplementary groups to a user
Comment 17 shridhar 2020-08-04 08:44:03 UTC 
Tested with following results.


]# rpm -q shadow-utils
shadow-utils-4.6-10.el8.x86_64
]# cat /etc/sssd/sssd.conf 
[sssd]
services = nss, pam
config_file_version = 2
domains = LDAP

[nss]

[pam]

[domain/LDAP]
debug_level = 9
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = dc=my-domain,dc=com
ldap_group_search_base = ou=Groups,dc=my-domain,dc=com
id_provider = ldap
auth_provider = ldap
ldap_group_object_class = posixGroup
ldap_user_object_class = posixAccount
ldap_schema = rfc2307
ldap_uri = ldap://my-domain.com
ldap_tls_cacertdir = /etc/openldap/cacerts

[root@ci-vm-10-0-137-249 tmp.36cqGpUzYF]# getent passwd -s files localuser_test
localuser_test:x:1000:1000::/home/localuser_test:/bin/bash
[root@ci-vm-10-0-137-249 tmp.36cqGpUzYF]# egrep ldapgroup /etc/group
[root@ci-vm-10-0-137-249 tmp.36cqGpUzYF]# getent group ldapgroup
ldapgroup:*:100000:ldaptester
[root@ci-vm-10-0-137-249 tmp.36cqGpUzYF]# usermod -a -G ldapgroup localuser_test
usermod: group 'ldapgroup' does not exist


I think we could return a error message about the failure of usemod operation. Here error message mentions that 'group does not exist'. That is not true. A ldap-group with name 'ldapgroup' does exist. This might confuse users.
Do you think that error message could be improved upon current error message?

Marking verified as usermod is returning error on failure of usermod operation.
Comment 18 Steeve Goveas 2020-08-05 05:26:21 UTC 
setting needinfo on comment 17
Comment 19 Iker Pedrosa 2020-08-05 07:12:36 UTC 
Shridhar and I spoke about this point and agreed that a rewording of the message is necessary. I'll propose a patch upstream to take care of it, but it won't be available for RHEL8.3.
Comment 22 errata-xmlrpc 2020-11-04 01:42:09 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 (shadow-utils 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-2020:4467
Note You need to log in before you can comment on or make changes to this bug.