2013/5/29 Bill Shannon <bill.shannon_at_oracle.com>
> Craig Perez wrote on 05/28/13 15:00:
>
>
> -------- Original Message --------
> Subject: Re: request asarch review for deploy command enhancement in
> GlassFish
> From: Bill Shannon <bill.shannon_at_oracle.com> <bill.shannon_at_oracle.com>
> To: Craig Perez <craig.perez_at_oracle.com> <craig.perez_at_oracle.com>
> CC: 吕宋平 <lvsongping_at_gmail.com> <lvsongping_at_gmail.com>,
> dev_at_glassfish.java.net, hong.hz.zhang_at_oracle.com
> Date: Tuesday, May 28, 2013 5:40:39 PM
>
> Craig Perez wrote on 05/28/13 13:48:
>
>
>> Beyond that I think there are a few other items to consider:
>>
>> A) An option to disable the deployuri command completely should the
>> administrator be concerned
>>
>> Do you think we need a special option just to control this, or can it
>> wait until we have a more general permission framework and support for
>> roles?
>> I think we can wait until we have a more general permission framework
>> and support for roles, what do you think?
>>
>
> [Craig] A simple approach ahead of a more general role based framework
> would probably help sooth the concerns of those that consider the secure
> production environment as their target. Would there be some way of having a
> local command that controls disablement and/or some of the config settings?
> Perhaps just removing a module or updating configuration that is not domain
> specific? The reverse could also be considered, add a module or non-domain
> config to enable deploy with URI which of course is not as developer
> friendly?
>
>
>> B) An option to limit the URI types that would be allowed
>>
>> This seems reasonable. An attribute or property set with "asadmin set"
>> would probably be good enough.
>> Ok, I got it! How will support an option to limit the URI types which
>> called --types instead of support an attribute or property set with
>> “asadmin set”?
>>
>
> [Craig] I'm not sure I understand what is being asked. Is this related to
> where configuration lives or what mechanism is used to change options.
>
> Limiting the URI types could be used to address both (A) and (B):
>
> $ asadmin set server.deployment.allowedUriTypes="http,file"
> (equivalent to the default, perhaps?)
>
> $ asadmin set server.deployment.allowedUriTypes="http"
> (don't allow file: URLs)
>
> $ asadmin set server.deployment.allowedUriTypes=""
> (don't allow anything, effectively disabling the deployuri command)
>
> Exact "dotted name" is TBD; the above is just an example.
>
>
> [Craig] Please keep in mind that if the same level of permission is needed
> to change the configuration remotely as to issue the command remotely with
> URI then risk is still present.
>
> Yes. We need to decide whether we're preventing accidents or really
> securing the server. Securing the server from the administrator, who can
> deploy code that runs in the server, is a significant challenge. If
> different administrators had different privileges, we could restrict the
> use of the "asadmin set" command.
>
> We could create a local-only command to control this option. Do you have
> any better ideas of how to control this?
>
> [Jeremy] I still can't find any better ideas to control this right now.
> Keep on thinking about this situation later.
>
>
>> C) Allow for specification of a "sandbox" area use as the download
>> location to better control permissions, ownership, quotas, disk space, etc.
>>
>> Uploaded apps are already stored in a special area, is that not good
>> enough?
>> Shall we need to make some external file directories which will be
>> regarded as download location? If it is needed, How about creating a file
>> named as
>> “download_file”which will be created under the directory
>> of domain/domain1?
>>
>
> [Craig] Hong may have more comment/experience on the current application
> deployment folder(s) usage. I was thinking of a place outside the domain
> that could have more restrictions in place. The current folder or new
> folder as suggested may be fine, I thought I recall some mention of using
> the /tmp area?
>
> What additional restrictions would there be for this other location, and
> what software would be applying the restrictions?
>
> Do you view this as a "staging" area, with the application being copied to
> the usual location after being "verified" in some way?
>
>
> [Craig] Yes that would be one option for what I was thinking, there might
> be duplication of files to consider but that may already be issue with
> multiple machine domain deployments already? The additional restrictions
> are as as I mentioned above applied in their simplest form by the OS/Kernel
> with file permissions, quotas, etc. and perhaps even a potential for some
> virus scanning to be applied?
>
> I guess I'm not quite sure how you imagine this would work...
>
> Would I create a separate filesystem area, with separate quotas, and then
> if the app is uploaded to this staging area and doesn't exceed the
> filesystem quota we would consider it ok to copy it to the real app
> directory where different quotas, if any, apply?
>
> Similarly, how would different file permissions for the staging area help?
>
> Adding hooks for a virus checker (again, a separate project) seems like a
> good thing, but I'm not sure how using a staging directory would help that.
>
> [Jeremy]Here's some points of mine:
1). Do you still remember the .gfclient exists in the directory of $User?
Maybe we can create a file called .download_apps as a staging directory
under the same directory of .gfclient.
2). If the name of the application we downloaded remotely is same with
the application exists in the staging area, we can delete the original
application in the staging area and continue to download the remote
application after being "verified"(if the app is downloaded to this staging
area and doesn't exceed the filesystem quota we would consider it ok to
deploy it to the real app directory)
Anyway, if we don't create a directory automatic, I think the following
suggestion will be helpful:
1). From the client side, we can also support an option called
--localTemp as a primary parameter to store the application downloaded
remotely.
2). From the administrator side, we can support a virus scanning to
specify which directory to store the application downloaded remotely.
3). Continue the operation to deploy the application.
I don't know whether my points is good. I just present it to see whether it
is fine.