cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: Open up ports beyond 80/443/8080 for downloading templates
Date Wed, 31 Jul 2013 21:56:41 GMT
Just a security measure, AFAIK. Since this is user-provided input, it
causes CloudStack to blindly (CloudStack does not have any blacklists for
example) to contact the supplied server. Presumably if the supplied server
has the standard ports open, it has a WAF to defend itself.


On 7/30/13 10:58 PM, "Thomas O'Dowd" <tpodowd@cloudian.com> wrote:

>I guess what I still don't understand is why restrict urls to certain
>ports? If the ports are not open it will cause an error. If the ports
>are open it will work (assuming the protocol is implemented on that
>port). For example, for register template if I choose a closed port then
>give me a connection error and ask me to try again. Even a currently
>valid port such as 8080 may be closed so it's the same thing really.
>Anyway, if I read Prasanna's mail correctly, it seems like there used to
>be a reason but its probably no harm to open things up?
>
>Tom.
>
>On Tue, 2013-07-30 at 16:41 +0000, Min Chen wrote:
>> Prasanna,
>> 	Based on your comment, what will happen if we remove that check and
>>still
>> NFS as secondary storage? In that case, register template is still done
>> through
>> SSVM. Any side effect? I had the same question as Tom when I was doing
>> object store refactoring, but hesitated to remove it because of not
>> knowing the history of it.
>> 
>> 	Thanks
>> 	-min
>> 
>> On 7/29/13 11:45 PM, "Prasanna Santhanam" <tsp@apache.org> wrote:
>> 
>> >On Tue, Jul 30, 2013 at 03:37:39PM +0900, Thomas O'Dowd wrote:
>> >> Thanks Ian. I had a look at this file. It's an easy fix to remove the
>> >> check from here but it's a general utility function so will also
>>affect
>> >> other uris... If there is no reason to limit any uri to those ports
>>then
>> >> I'd like to remove this check and open them up.
>> >> 
>> >> Interested to hear opinions,
>> >
>> >This is probably because earlier one would interact only with the SSVM
>> >to download any images off of secondary storage. With 4.2 that ability
>> >is transferred to the image store like say s3/cloudian and one can get
>> >direct http access to the image on the object store. The code in
>> >validateUrl assumes that the url check goes always to the SSVM on
>> >which only 80/443/8080 are open by default.
>> >
>> >-- 
>> >Prasanna.,
>> >
>> >------------------------
>> >Powered by BigRock.com
>> >
>> 
>
>-- 
>Cloudian KK - http://www.cloudian.com/get-started.html
>Fancy 100TB of full featured S3 Storage?
>Checkout the Cloudian® Community Edition!
>


Mime
View raw message