Control: severity -1 normal
(fixing the typo in the Control line)
On 2017-08-21 21:47:04 +0200, Arthur de Jong wrote:
> Control: sevirity -1 normal
>
> On Mon, 2017-08-21 at 13:17 +0200, Vincent Lefevre wrote:
> > Severity: grave
> > Justification: causes non-serious data loss and DoS from an end user.
>
> The severity is a bit questionable and, at the very least not a flaw in
> or unique to nslcd.
Perhaps not unique to nslcd, but the consequences are the worst when
nslcd is killed: one can no longer access to the machine.
> Any local user that does not have resource limits applied to them
> can DoS the whole system easily so I'm lowering the severity to
> normal.
Note that users here are not malicious (they would have serious
problems if they DoS the whole system on purpose). Memory can be
exhausted by mistake (e.g. due to bugs) or just because the users
try to push the limits to solve some problems, and for this reason,
there are no resource limits. Still, one expects that the system
reacts in a reasonable manner if possible, e.g. the whole machine
should not crash and should remain accessible.
> The OOM is indeed a bit of Russian roulette on your system. You can
> tune it a bit with vm.panic_on_oom and vm.overcommit_memory sysctls or
> perform the following action that is equivalent to what newer nslcd
> does:
>
> echo -1000 > /proc/`cat /var/run/nslcd/nslcd.pid`/oom_score_adj
I suppose that a workaround based on this in /etc/init.d/nslcd could
be after "start-stop-daemon --start ...":
status=$?
if [ $status -eq 0 ]; then
echo -1000 > /proc/`cat $NSLCD_PIDFILE`/oom_score_adj
fi
log_end_msg $status
;;
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
