On Sun, Oct 23, 2011 at 6:55 PM,
Platonides<Platonides(a)gmail.com> wrote:
I don't know why it needs to trim the images
generated by LilyPond, but
there's probably a reason for that.
Assuming that LilyPond code doesn't allow to open files, or execute
programs, the current version of LilyPond is apparently safe.
From my memory of reading bug 189 a few years ago, the biggest concern
Tim had at
the time was that Lilypond does not (or, at least, at the
time did not; I haven't kept up with LilyPond development news at all)
limit memory or time usage. For certain pathological (or well-crafted,
if you're an attacker) inputs, the process of converting LilyPond
syntax to an image with sheet music may consume a very large amount of
time and/or memory. From my casual re-reading it seems that it's quite
easy to write an infinite loop in LilyPond. LilyPond does have a safe
mode, but it does not protect against infinite loops, nor does it
claim to. Clearly, this presents a resource exhaustion / denial of
service vulnerability given that certain inputs can cause the LilyPond
interpreter to run forever, and any user that can edit or even preview
pages can inject such inputs.
So in order to run LilyPond on WMF servers and be able to feed it
arbitrary user input while protecting against resource exhaustion, we
need to be able to limit the amount of time and memory that each
LilyPond process can use, either in LilyPond itself or in the
MediaWiki extension that spawns LilyPond processes. To my knowledge,
no one has volunteered for this task so far.
Roan
Linux provides the setrlimit() system call for this purpose -- you could
either call it as a wrapper around lilypond, or hack it into a de-fanged
version of Lilypond.
If you're going to be running an auxiliary rendering process or
special-use server anyway, a few moments Googling finds the "softlimit"
program, provided as part of the daemontools package, which looks like
it is intended for providing the sort of limited sandboxing required here.
- Neil