Date: Thu, 26 Mar 2015 12:50:27 -0500 From: Matthew Pherigo <hybrid120@gmail.com> To: Michael Ross <gmx@ross.cx> Cc: Rick Miller <vmiller@hostileadmin.com>, FreeBSD Users <freebsd-questions@freebsd.org> Subject: Re: 'pw usermod -G' not removing user from group? Message-ID: <3450412217143430232@unknownmsgid> In-Reply-To: <op.xv36a3e6g7njmm@michael-think.fritz.box> References: <474FEC65-4E15-4972-A411-E91569B4E2A5@gmail.com> <CAHzLAVHJncOcHvb_fxS4xsN8t9pvavLjpWmvxbhP2kyVHsP9GQ@mail.gmail.com> <3183757859924107912@unknownmsgid> <CAHzLAVFGHnEhWEJKRZZF-R=y401a5FEc5a9s2-YhGom5sRuR2w@mail.gmail.com> <E2CCC68D-AED8-4019-B7ED-46F7BB2094EF@gmail.com> <CAHzLAVFu%2B4u8PwfWW=JX24E5h_OmnQfj7foa7q0=ttBxJX6mAw@mail.gmail.com> <op.xv36a3e6g7njmm@michael-think.fritz.box>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 26, 2015, at 12:04 PM, Michael Ross <gmx@ross.cx> wrote: > >> On Thu, 26 Mar 2015 16:37:11 +0100, Rick Miller <vmiller@hostileadmin.com> wrote: >> >> On Thu, Mar 26, 2015 at 10:24 AM, Matthew Pherigo <hybrid120@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3450412217143430232>