Bug 813406 - lgroupmod -M can corrupt the format of /etc/group
Summary: lgroupmod -M can corrupt the format of /etc/group
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libuser
Version: 6.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miloslav Trmač
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-17 16:35 UTC by Miroslav Vadkerti
Modified: 2012-04-18 08:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-18 08:14:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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