@Isak Anything run with the `backticks operator` runs with the same privileges 
as the process which launched them, if using system level sandboxing, or if 
using some crazy sandbox built in to ruby (which probably wouldn't be very 
good, but maybe good enough) it'd probably just disable backticks feature.


On 01/04/2012, at 9:31 PM, Isak Andersson wrote:

> Well. Isn't it kind of possible to just hack the gem installation in using 
> the ruby quotes that execute code on the system. I can't type them on the 
> phone but I think you know what I mean. Kind of a security issue isn't it?
> 
> Anyways. Perhaps we could offer some Gems to pick from that we think are 
> quality! (rack_csrf, scrypt).
> -- 
> Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
> 
> Jenna Fox <a...@creativepony.com> skrev:
> I don't think we need to go as far as automatically installing gems - 
> securing ruby is a pretty big challenge, but securing gcc? no way.
> 
> —
> Jenna
> 
> On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote:
> 
>> Remember that we should pretty much make a Gemfile mandatory if the user 
>> makes use of gems other than Camping. For example, rack_csrf. And we should 
>> make sure that dependencies get installed. :)
>> -- 
>> Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
>> 
>> Jenna Fox <a...@creativepony.com> skrev:
>>> 
>>> Hm. I know the main guy responsible for App Engine, and, well, I certainly 
>>> wouldn't build a platform atop it - even aside from the huge glaring issue 
>>> that to have an app which can store data persistently, you need to use 
>>> google's proprietary database software.
>>> 
>>> Heroku doesn't screen against abuse at all. Heroku is not a 'shared 
>>> hosting' provider. Their systems use the very finest jailing techniques to 
>>> lock the ruby process in to it's own little world. It has no writable 
>>> filesystem and it can only read what it absolutely needs to be able to read 
>>> to function. All data storage happens over the network on separated 
>>> database servers. The only type of abuse they need to be weary of is people 
>>> using their servers to do illegal things - bullying, sharing illegal 
>>> content, that sort of thing. They deal with that the same way any provider 
>>> does - wait till someone makes a complaint. Matz, inventor of ruby, works 
>>> for heroku making exactly this sort of stuff work extremely well.
>>> 
>>> Still, it's not as friendly as it could be, and I personally think the 
>>> trade offs on heroku are not very good for beginners (you have to use a 
>>> complex database system, and cannot use the filesystem to store anything 
>>> but static assets).
>>> 
>>> Good work getting this server up David! I'm pretty excited. It sounds like 
>>> you're having some pretty annoying deployment issues. As it's being quite a 
>>> hassle, perhaps we should be thinking more deeply about creating our own 
>>> special server for this task - something like the modified unicorn I 
>>> mentioned earlier somewhere.
>>> 
>>> —
>>> Jenna
>>> 
>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>> 
>>>> Wonder if Google might help getting camping to run on app engine?
>>>> 
>>>> On 1 April 2012 10:03, david costa <gurugeek...@gmail.com> wrote:
>>>>> Ah I forgot
>>>>> you can compare camping running on thin here
>>>>> http://run.camping.io:3301/
>>>>> vs passenger at http://run.camping.io
>>>>> 
>>>>> apparently db has some problems with fusion passenger  (see 
>>>>> http://run.camping.io create HTML page and test HTML page. The same code 
>>>>> on thin works just fine... umhh oh no don't feel like more debugging ):
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, Apr 1, 2012 at 9:51 AM, david costa <gurugeek...@gmail.com> wrote:
>>>>>> Okay :D after many many hours of testing I am settled for nginx and 
>>>>>> passenger.
>>>>>> live at http://run.camping.io/
>>>>>> 
>>>>>> I did try every apache combination (with passenger, with cgi, etc. etc.) 
>>>>>> as is simply not really working fine.
>>>>>> I tried some other obscure web servers too but apparently this seems to 
>>>>>> work fine for now :) other servers would run the app as CGI or FastCGI. 
>>>>>> I am not worried about speed just ease of deployment and nginx with 
>>>>>> passenger seems to do the job for now. The alternative is nginx as 
>>>>>> reverse proxy but as Jenna rightly pointed out it would spawn a lot of 
>>>>>> thin instances that might or might not be used.
>>>>>> 
>>>>>> I did throw the sponge at Webdav on apache. It doesn't work as expected 
>>>>>> and not with all clients. It seems more suitable to store quick files 
>>>>>> than something else.
>>>>>> Can try tomorrow with nginx but perhaps it would be nicer to have a 
>>>>>> quick camping hack to upload  a file etc. but you can't just automate it 
>>>>>> entirely else you can have people running malicious code 
>>>>>> automatically... 
>>>>>> 
>>>>>> I can do the shell scripts to create virtual users for nginx and dns. 
>>>>>> Another option is to give a normal hosting for camping users. It 
>>>>>> wouldn't be an issue to have 100-200 trusted users to have access to 
>>>>>> this e.g. we can build a camping fronted  for users to apply with a 
>>>>>> selection e.g. their github account, why they want the deployment 
>>>>>> hosting etc. and then once approved we would give them a normal account 
>>>>>> that would allow them to upload files on SFTP and may be even shell 
>>>>>> (which BTW is something you don't have on heroku and other services. Of 
>>>>>> course this could be protected for security or given only to active 
>>>>>> people. 
>>>>>> 
>>>>>> How does heroku screens against abuses?  
>>>>>> Anyway if some of you would like to be alpha users in this system let me 
>>>>>> know, I will be glad to set you up as soon as I am done testing 
>>>>>> subdomains etc. ;)
>>>>>> And of course if you have a better idea for a setup let me know.
>>>>>> 
>>>>>> Regards
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox <a...@creativepony.com> wrote:
>>>>>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>>>>>> 
>>>>>>> Or you could implement webdav as an application nginx proxies to, just 
>>>>>>> as it proxies to ruby instances.
>>>>>>> 
>>>>>>> —
>>>>>>> Jenna
>>>>>>> 
>>>>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>>>>>> 
>>>>>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <icepa...@lavabit.com> 
>>>>>>>> wrote:
>>>>>>>>> Actually setting up a reverse proxy gives better performance for the 
>>>>>>>>> end user As you can have some sort of buffer between them. The 
>>>>>>>>> Unicorn server takes care of whatever nginx asks for, and while it 
>>>>>>>>> waits it can server whatever unicorn outputs. It doesn't have to wait 
>>>>>>>>> for what it outputs itself to get done because you have a queue. Or 
>>>>>>>>> something like that.
>>>>>>>> 
>>>>>>>> Mh I am not really sure it would be a better performance as it would 
>>>>>>>> be anyway more than one process. I think that phusion passenger is 
>>>>>>>> pretty much the most robust solution for this.
>>>>>>>>> 
>>>>>>>>> Some people actually out Apache to do PHP stuff while nginx acts as a 
>>>>>>>>> reverse proxy and actually shows things to the user in the same way 
>>>>>>>>> you'd do with Unicorn/Thin
>>>>>>>> 
>>>>>>>> Well this would be even more load as two web servers will run at the 
>>>>>>>> same time. Apache + Phusion passenger already lets you run .php or 
>>>>>>>> anything you want.
>>>>>>>> 
>>>>>>>> But this is not the issue really. I think this is all fine in term of 
>>>>>>>> mono user. Question: if you have 100 users how do you configure it ? 
>>>>>>>> How can you add webdav support on the top of the Nginx + unicorn setup 
>>>>>>>> ?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> But perhaps That's too much for a server ment to serve other peoples 
>>>>>>>>> applications! Then you have to scale down the resources used.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I am open to anything but if I can't do something I might ask for some 
>>>>>>>> brave volunteers to set it up as I really never tried anything else 
>>>>>>>> beside for local/quick test deployment.  
>>>>>>>> _______________________________________________
>>>>>>>> Camping-list mailing list
>>>>>>>> Camping-list@rubyforge.org
>>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Camping-list mailing list
>>>>>>> Camping-list@rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list@rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>> 
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>> 
>>> Scarica Subito la Musica pi Trendy sul Tuo Telefonino 
>>> http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
>> 
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
> 
> Download de gratis Registry Scan om het problem te vinden!
> http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
> _______________________________________________
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Reply via email to