On 23/10/11 19:36, Roan Kattouw wrote: > On Sun, Oct 23, 2011 at 6:55 PM, Platonides<[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
