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>
> To: Craig Perez <craig.perez_at_oracle.com>
> CC: 吕宋平 <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 thinkwe 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?
>>>>
>>>>> 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.