[wildfly-dev] Shall we limit size of the deployment in WildFly?

[Tristan Tarrant]

While we're on filesystem space availability, for monitoring purposes, 
would it be possible to expose this as a runtime metric for known server 
locations (data, tmp, logs) ?

Tristan

On 04/11/2015 13:37, Jason T. Greene wrote:
> On Nov 3, 2015, at 7:14 PM, Lin Gao <lgao at redhat.com> wrote:
>
>>>> On 11/03/2015 02:41 AM, Lin Gao wrote:
>>>> Hi,
>>>>
>>>>    WildFly does not limit the deployment file size, users with appropriate
>>>>    privilege(deployer) can select any file to deploy from both CLI and web
>>>>    console.
>>>>
>>>>    For the too big file, it may exhaust all available disk space, and in
>>>>    some cases, even small file can exhaust the disk space if the current
>>>>    disk space is not big enough.
>>>>
>>>>    So shall we limit file size of the deployment in WildFly? or shall we
>>>>    limit the available disk space? or shall we just show a warning message
>>>>    to users?
>>>>
>>>>    If we do, where in the management API configuration for this should be
>>>>    done, if it is done this way?
>>>>
>>>>    Arbitrary limits will break users, so if we have an arbitrary limit it
>>>>    needs to be easily adjusted.
>>>>
>>>>    In case of domain mode, different hosts may have different disk space,
>>>>    which means they are likely have different capacity to hold deployment
>>>>    files. For example, servers in server-group-A may have 2GB available
>>>>    disk space, servers in server-group-B may have 200MB available disk
>>>>    space. An unified limit for the whole domain seems not fair for the
>>>>    servers with more available disk space.
>>>>
>>>>    Also, WildFly does not limit type of the deployment file, but it might
>>>>    need a separate discussion if necessary?
>>>>
>>>>    Any thoughts?
>>>
>>> Is this in response to a real observed problem?
>>
>> Yes it is.
>
> My understanding was that this was reported by a user but it was reported as something they were concerned with, and not actually something that was occurring in their environment.
>
> I agree with David that disk quotas on the processing running the app server is the most appropriate solution to prevent interference with other processes.
>
> I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G)
>
> We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support).
>
> IMO this one is pretty low priority, but perhaps those that monitor this list see it as a need. If so can you speak up?
>
>
>
>>
>>> In general, if the user
>>> doesn't have space for a deployment, the deployment will fail with an
>>> error and (I am fairly certain) will delete the partial deployment.  If
>>> there is space, then the deployment will succeed regardless of size.
>>
>>> It's interesting that the JIRA you reference speaks in terms of
>>> security.  If an admin wants to lock down storage space, it's probably
>>> best to do it at the operating system level using e.g. disk quotas -
>>> there are too many ways to get the application server to write arbitrary
>>> amounts of data to the file system, regardless of the presence of a
>>> security manager or any other application-level control.
>>>
>>> I'm pretty sure that if an attacker has permission to upload deployments
>>> to the server, they already essentially have control over the server.
>>> This should be an OS level concern.
>>
>> The JIRA in question was a 'bug' related to security at first, after several
>> rounds of discussion, it is agreed that it is not a security vulnerability, but
>> an 'Enhancement'.
>>
>> The proposed requirement for the enhancement is:
>>
>> Provide an option in config to alert user that
>> a) File is larger than a configurable limit
>> b) File type is/is not valid.
>>
>> but it may need more discussion in community on both the requirement and design
>> if it will be done, that is why this thread comes out in first place. :-)
>>
>>>>    FYI: https://issues.jboss.org/browse/WFCORE-1057
>>
>> Best Regards
>> --
>> Lin Gao
>> Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat