[wildfly-dev] Shall we limit size of the deployment in WildFly?
David M. Lloyd
david.lloyd at redhat.com
Tue Nov 3 08:19:38 EST 2015
On 11/03/2015 02:41 AM, Lin Gao wrote:
> 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? 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.
> 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
More information about the wildfly-dev