Bug 1727236

Summary:	usermod fails to report failure while adding local user to network group
Product:	Red Hat Enterprise Linux 8	Reporter:	Arpit Tolani <atolani>
Component:	shadow-utils	Assignee:	Iker Pedrosa <ipedrosa>
Status:	CLOSED ERRATA	QA Contact:	sssd-qe <sssd-qe>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	dapospis, ipedrosa, nmavrogi, pkulkarn, sgadekar, sgoveas, ssorce, tmraz
Target Milestone:	beta	Keywords:	Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:	sync-to-jira
Fixed In Version:	shadow-utils-4.6-10.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-04 01:42:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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