Date: Thu, 26 Mar 2015 09:24:58 -0500 From: Matthew Pherigo <hybrid120@gmail.com> To: Rick Miller <vmiller@hostileadmin.com> Cc: FreeBSD Users <freebsd-questions@freebsd.org> Subject: Re: 'pw usermod -G' not removing user from group? Message-ID: <E2CCC68D-AED8-4019-B7ED-46F7BB2094EF@gmail.com> In-Reply-To: <CAHzLAVFGHnEhWEJKRZZF-R=y401a5FEc5a9s2-YhGom5sRuR2w@mail.gmail.com> References: <474FEC65-4E15-4972-A411-E91569B4E2A5@gmail.com> <CAHzLAVHJncOcHvb_fxS4xsN8t9pvavLjpWmvxbhP2kyVHsP9GQ@mail.gmail.com> <3183757859924107912@unknownmsgid> <CAHzLAVFGHnEhWEJKRZZF-R=y401a5FEc5a9s2-YhGom5sRuR2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your email, Rick. While I understand the necessity of the securit= y-patch-only limitation, I would argue that this issue actually IS a securit= y 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 si= nce the admin has just shown that he doesn't need or want this user to be pa= rt of the group, he won't attempt to access those group resources by the use= r unless he is explicitly testing it. I only noticed this bug because Salt h= ad a test case for it. Case 3: admin needs to remove one group and add another. The new group is ad= ded correctly, but the old group is not removed. It's much more likely that t= he addition will be noticed while the failed removal will not. I would argue that this is much more dangerous than the opposite (Addition o= f groups failing but removal of groups succeeding), as giving an account too= much privilege is a security risk while an account not having enough privil= ege is simply an inconvenience. Hopefully this can be resolved soon. --Matt > On Mar 26, 2015, at 7:28 AM, Rick Miller <vmiller@hostileadmin.com> wrote:= >=20 >=20 >=20 >> On Wed, Mar 25, 2015 at 5:18 PM, Matthew Pherigo <hybrid120@gmail.com> wr= ote: >> Thanks, Rick! It's crazy that they didn't allow it in; seems like a prett= y big issue. Hopefully they'll release a patch through FreeBSD-update soon. I= n the meantime, do you or anyone else know how to work around this? >=20 > I believe it's unlikely to hit releng/10.1, but I could be wrong. The rea= son I don't think it will be merged is because RE and/or security officer pr= obably don't believe it fits the criteria for merging into a releng branch, w= hich typically only receive security and errata updates. That said, because= it did get merged into stable/10, it will be included in releng/10.2. >=20 > I merged the patch from stable/10 into our internal development branches s= o that it would be available in our internal distributions. It was caught i= n time so that we did not have to go to great lengths to get it deployed. I= t was simply a matter of compiling the distribution. For systems already in= stalled it is necessary to apply the patch to the sources and recompile and r= einstall base. >=20 > --=20 > Take care > Rick Miller
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E2CCC68D-AED8-4019-B7ED-46F7BB2094EF>