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

Stuart Douglas stuart.w.douglas at gmail.com
Wed Nov 4 04:26:33 EST 2015


Is this actually a real world problem that users are running into?

If not then adding any kind of limit seems like it has the potential to
cause more problems than it will solve.

As others have pointed out I think the security angle is moot, as if you
can deploy to the server your deployment can DOS the server in any number
of ways, security manager or no security manager (the simplest way is just
to put while(true){} in a Servlet then send some requests, after a while
you will lock up every web thread and use 100% CPU, and there is no way to
configure the security manager to stop this).

Stuart

On Wed, 4 Nov 2015 at 20:12 Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

>  From within GWT is there any option to detect the file size before
> uploading?
>
> I wonder if it is better if we had something where we ask the server
> "Can you accept a file of size X?" before commencing an upload rather
> than setting some arbitrary limit.  Something like that could also be
> used in domain mode before deployments are distributed allowing them to
> fail early.
>
> You may have 8Gb free on your disk and have 2Gb deployments, after a
> couple of deployments the space would be gone but the arbitrary value
> would still allow 2Gb uploads.
>
> Regards,
> Darran Lofthouse.
>
>
> On 04/11/15 01:13, Lin Gao 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.
> >
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/c7a78e93/attachment.html 


More information about the wildfly-dev mailing list