'pw usermod -G' not removing user from group?
vmiller at hostileadmin.com
Thu Mar 26 17:49:43 UTC 2015
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>
> On Thu, Mar 26, 2015 at 10:24 AM, Matthew Pherigo <hybrid120 at gmail.com>
>> 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
>>> part of the group, he won't attempt to access those group resources by
>>> 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
>>> 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
>> You may consider opening a PR for this if one is not already open.
> 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.
More information about the freebsd-questions