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

[Darran Lofthouse]

+1 That is why I am thinking if any check is needed can it be a 
meaningful check such as "Is there room to store the file I am about to 
upload" rather than some arbitrary value which will be wrong for someone 
and as I point out even if you allow a large value that still does not 
actually solve the problem.

On 04/11/15 09:26, Stuart Douglas wrote:
> 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
> <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>