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

Reply via email to