On Thu, Mar 13, 2008 at 04:06:55PM -0400, Justin Pryzby wrote: > On Thu, Mar 13, 2008 at 08:32:39PM +0100, Thomas Rasmussen wrote: > > On Thu, Mar 13, 2008 at 4:30 PM, Nicolas François <[EMAIL PROTECTED]> wrote: > > > > On Thu, Mar 13, 2008 at 01:30:45PM +0100, [EMAIL PROTECTED]: > > > > If /etc/gshadow file has been changed so two otherwise non-identical > > > > groups apear with the same groupname, usermod will loop and use all > > > > memory > > > > on system if called. > > > > > > > > Reproducable by performing this: > > > > # groupadd tr > > > > # groupadd rtr > > > > # useradd -g tr tr > > > > # perl -pi -e 's/rtr/tr/g' /etc/gshadow > > > > # usermod -G tr tr > > > > <observe usermod using memory and proc time> > > > > > > > > Tested and reproduced on latest (4.0r3) netinst iso image and updated > > > > with all packages. > > > > I don't think this bug is that critical. I doesn't cause any > > > corruption, and it occurs only in case of configuration errors, > > > which do not appear if the administrators use the recommended > > > tools for user/group administration. Thus I will not issue a fix > > > for this bug. > > > I agree that this should not be seen as admins should use the dedicated > > toos, but I still see this as a quite serious bug because it will crash > > either the system or random services running on the system when it hits the > > maximum amount of memory. > Really? If usermod spins and sucks up memory, it *should* just get > killed for OOM, perhaps after causing some disk usage. Other > processes might be affected by IO time, CPU usage and such, but I > think neither the whole system nor any services should become > unavailable (just their response time might suffer). Nevermind, after trying it, I take that back. It has a large effect on the system probably because it necessarily runs as root, so OOM probably hesitates to kill it.
Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
