Re: Open up ports beyond 80/443/8080 for downloading templates

[Prasanna Santhanam <ts...@apache.org>]

My mistake. Didn't read the bug report clearly. So mgmt server would
need to know ahead of time to allow ports considered safe by the admin
so it can program that during SecStorageSetupCommand. 

On Wed, Jul 31, 2013 at 04:41:16PM +0000, Min Chen wrote:
> Hi Prasanna,
> 
> 	I think what Tom and I mentioned is the url provided in registering a
> template, which is totally different from the endpoint.url for the object
> store. I still could not understand your suggestion.
> 
> 	Thanks
> 	-min
> 
> On 7/31/13 2:47 AM, "Prasanna Santhanam" <ts...@apache.org> wrote:
> 
> >What can be done is to include into validateUrl the port provided in
> >the endpoint.url from addImageStore API . That will satisfy both
> >objectstore and NFS based storage. The unorthodox port that comes from
> >object store will anyway be closed on the SSVM so it will return a
> >connection-refused.
> >
> >Would that solve the problem albeit in a hacky way?
> >
> >In the future we could dissociate the dependency of the ports for
> >download from the validity of the url generated itself.
> >
> >On Wed, Jul 31, 2013 at 02:58:43PM +0900, Thomas O'Dowd 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" <ts...@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!
> >
> >-- 
> >Prasanna.,
> >
> >------------------------
> >Powered by BigRock.com
> >

-- 
Prasanna.,

------------------------
Powered by BigRock.com