'pw usermod -G' not removing user from group?

[Matthew Pherigo]

> On Mar 26, 2015, at 12:04 PM, Michael Ross <gmx at ross.cx> wrote:
>
>> On Thu, 26 Mar 2015 16:37:11 +0100, Rick Miller <vmiller at hostileadmin.com> wrote:
>>
>> On Thu, Mar 26, 2015 at 10:24 AM, Matthew Pherigo <hybrid120 at gmail.com>
>> wrote:
>>
>>> Thanks for your email, Rick. While I understand the necessity of the
>>> security-patch-only limitation, I would argue that this issue actually IS a
>>> security risk, like so:
>>>
>>> Case 1: admin needs to add a user to a group. This works correctly.
>>> Case 2: admin needs to remove a user from a group. This doesn't work, but
>>> since the admin has just shown that he doesn't need or want this user to be
>>> part of the group, he won't attempt to access those group resources by the
>>> user unless he is explicitly testing it. I only noticed this bug because
>>> Salt had a test case for it.
>>> Case 3: admin needs to remove one group and add another. The new group is
>>> added correctly, but the old group is not removed. It's much more likely
>>> that the addition will be noticed while the failed removal will not.
>>>
>>> I would argue that this is much more dangerous than the opposite (Addition
>>> of groups failing but removal of groups succeeding), as giving an account
>>> too much privilege is a security risk while an account not having enough
>>> privilege is simply an inconvenience.
>>
>> Just a quick nitpick...on mailing lists where threads can often be very
>> lengthy it is generally accepted that inline posting is preferred to
>> top-posting.  This practice helps to maintain the readability of a thread.
>>
>> That said, after closer inspection, the behavior you described is not
>> identical to the behavior described and illustrated in the PR referenced.
>> Chalk it up to me not reading your post closely enough.  My apologies.
>> PR187189 specifically addresses duplicate groups with differing ID's where
>> the behavior you're experiencing, while similar, does not include duplicate
>> groups.
>>
>> You may consider opening a PR for this if one is not already open.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185666
>
> dated 2014/01/11, patched 2014/10/28 and 2014/11/04

Oh dear, that describes the behavior I'm experiencing exactly. I'll
test this out on a fresh install; if it still happens there, then it
must be another regression? Thanks for showing me this PR, Michael.

--Matt