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
