<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">googling i found the ulimit should take care of memory usage :<div><br><div><div><a href="https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage">https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage</a></div><div><br></div><div><a href="http://ss64.com/bash/ulimit.html">http://ss64.com/bash/ulimit.html</a></div></div><div><br><div><div>On Mar 11, 2014, at 1:20 AM, epi <<a href="mailto:massimodisasha@gmail.com">massimodisasha@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 11, 2014, at 12:36 AM, Hamish <<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Massimo wrote:<br><br><blockquote type="cite">Is my understanding that the grass parsing code has to be<br>“less restrictive” for the desktop app while the sanitizer<br>has to be implemented on the web-ui side.</blockquote></blockquote><blockquote type="cite"><br>the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account.</blockquote><blockquote type="cite"><br>but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect.<br></blockquote><div><br></div><div><div>gotcha.</div><div>I personally think of the web-ui user as a trusted user with his own home on the server, </div><div>but i agree about the need to have an extra layer of security on the web-ui to check user inputs </div><div>(a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) </div></div><br><blockquote type="cite"><br>? Is this not true:<br>Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose.<br><br><br></blockquote><div><br></div><div><span style="background-color: rgb(255, 255, 255);">I see the implementation of the grass-web-shell as a second step in the web-ui development.</span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;">Most of its security issue depends by the user/admin needs.</span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;"><br></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. </span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">in my use case each </span></span><span style="line-height: 20px; background-color: rgb(255, 255, 255);">each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile)</span></div><div><span style="line-height: 20px; background-color: rgb(255, 255, 255);"> … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users.</span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;"><br></span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">When the security needs are a high priority, t</span></span><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">ools like </span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">docker [1] , lxc [2] , supervisors [3] </span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">will let us to have more control reducing security risk.</span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;"><br></span></span></div><div><span style="background-color: rgb(255, 255, 255);"><span style="line-height: 20px;">But</span></span><span style="background-color: rgb(255, 255, 255); line-height: 20px;"> this king of thing is isolated from the web-ui development.</span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;"><br></span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;">In any case the IPython-dev team is working hard on this direction, </span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;">they just released 2.0 and from the roadmap [4] </span></div><div><span style="background-color: rgb(255, 255, 255); line-height: 20px;">the multiuser interface will be released in the 3.0 version (coming out this summer)</span></div><div><br></div><div><span style="line-height: 20px; background-color: rgb(255, 255, 255);"><br></span></div><div><span style="line-height: 20px; background-color: rgb(255, 255, 255);">[1] </span><a href="https://www.docker.io/">https://www.docker.io/</a></div><div><span style="line-height: 20px; background-color: rgb(255, 255, 255);">[2] </span><a href="https://linuxcontainers.org/">https://linuxcontainers.org/</a></div><div>[3] <a href="http://supervisord.org/">http://supervisord.org/</a></div><div>[4] <a href="https://github.com/ipython/ipython/wiki/Roadmap:-IPython">https://github.com/ipython/ipython/wiki/Roadmap:-IPython</a></div><div><br></div><div>[5] <a href="https://github.com/cni/ipython-hydra">https://github.com/cni/ipython-hydra</a> an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook</div><div><span style="font-family: 'Lucida Grande', arial, sans-serif; line-height: 20px; background-color: rgb(255, 255, 255);"><br></span></div><br><blockquote type="cite"><br>--<br><br>As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :)</blockquote><blockquote type="cite"><br><br><br>regards,<br>Hamish<br><br></blockquote></div><br></div></blockquote></div><br></div></div></body></html>