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

[Rick Miller]

On Thu, Mar 26, 2015 at 12:48 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
>

Thanks, Michael...So, another PR exists for this behavior addressed by the
same patch.  The patch that was not merged into releng/10.1.  My original
statement still applies.  I cannot speak as to why the patch was not MFC'd
into releng/10.1 as I am unfamiliar with the exact criteria.  I can confirm
the patch works as it was tested within my environments.


-- 
Take care
Rick Miller