Bug 813406

Summary: lgroupmod -M can corrupt the format of /etc/group
Product: Red Hat Enterprise Linux 6 Reporter: Miroslav Vadkerti <mvadkert>
Component: libuserAssignee: Miloslav Trmač <mitr>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: mmalik
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-18 08:14:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Miroslav Vadkerti 2012-04-17 16:35:50 UTC
Description of problem:
lgroupmod -M doesn't check strings for ':'.

Version-Release number of selected component (if applicable):
libuser-0.56.13-5.el6

How reproducible:
Always

Steps to Reproduce:
# lgroupadd testgroup
# lgroupmod -M a:b:c,d:e:f testgroup
# grep testgroup /etc/group
testgroup:x:502:a:b:c,d:e:f

Actual Results:
lgroupmod -M accepts user name containing ':'.

Expected Results:
lgroupmod -M refuses user name containing ':'.

Comment 1 Miloslav Trmač 2012-04-18 08:14:48 UTC
Thanks for your report.

In general:

The last field on the line is special: adding colons to it does not add any field splitting ambiguity.  libuser therefore explicitly allows ':' in the last field.

glibc's parsers do not recognize the ':' as a separator in that case (in particular, you can have a ':' in user's shell).  On the other hand, shadow-utils's parsers do recognize the ':' as terminating even the last field on the line, so the situation is ambiguous.

Therefore, libuser will always differ from one of glibc and shadow-utils.

Given that the field splitting does not have any security impact, and the file format is not really strictly defined, I think leaving the existing code is fine.  We can't promise that it will work, but we don't have a really good reason to prohibit it, either.


In this specific case (also applies to the member list, but not the administrator list, in /etc/gshadow):
Anyone using the /etc/passwd file will not be able to add an user named "a:b:c", so any such invocation is invalid in any case, regardless of how glibc or shadow-utils interpret it.  (In theory, a user named "a:b:c" might be defined in LDAP, where the ":" character is not prohibited, and /etc/group could refer to it - but that's extremely brittle).


Please reopen this if I have overlooked a reason to prohibit the ':' in the last field.