googling i found the ulimit should take care of memory usage : https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage
http://ss64.com/bash/ulimit.html On Mar 11, 2014, at 1:20 AM, epi <massimodisa...@gmail.com> wrote: > > On Mar 11, 2014, at 12:36 AM, Hamish <hamis...@yahoo.com> wrote: > >> Massimo wrote: >> >>> Is my understanding that the grass parsing code has to be >>> “less restrictive” for the desktop app while the sanitizer >>> has to be implemented on the web-ui side. >> >> 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. >> >> 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. > > gotcha. > I personally think of the web-ui user as a trusted user with his own home on > the server, > but i agree about the need to have an extra layer of security on the web-ui > to check user inputs > (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) > >> >> ? Is this not true: >> 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. >> >> > > I see the implementation of the grass-web-shell as a second step in the > web-ui development. > Most of its security issue depends by the user/admin needs. > > I have an ipython notebook running on a remote server, it has a password and > runs in https with an ssl cert. > in my use case each each ipython instance runs on a specific port and use a > different ssl cert. (all this settings are stored in the ipytohn notebook > profile) > … It is not super-secure but is is enough from my needs, we are a small > group (4) of trusted and well known users. > > When the security needs are a high priority, tools like > docker [1] , lxc [2] , supervisors [3] > will let us to have more control reducing security risk. > > But this king of thing is isolated from the web-ui development. > > In any case the IPython-dev team is working hard on this direction, > they just released 2.0 and from the roadmap [4] > the multiuser interface will be released in the 3.0 version (coming out this > summer) > > > [1] https://www.docker.io/ > [2] https://linuxcontainers.org/ > [3] http://supervisord.org/ > [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython > > [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the > university of standford to allow a multiuser interface to the IPYthon notebook > > >> >> -- >> >> 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. :) >> >> >> >> regards, >> Hamish >> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
