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

>From what I learned of this thread, a service to expose the file system space availability needs to be implemented first, then provides a way to check whether the server locations("data") have enough disk spaces to store the uploaded file. Should we create a Jira for this? :-) Best Regards -- Lin Gao Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com&gt; > To: "Jason T. Greene" <jason.greene(a)redhat.com&gt;, "Tristan Tarrant" <ttarrant(a)redhat.com&gt; > Cc: wildfly-dev(a)lists.jboss.org > Sent: Wednesday, November 4, 2015 11:21:11 PM > Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? > > This would also be something ideal to report on in the "administrator > encouragement" service I keep meaning to look into again ;-) > > On 04/11/15 15:02, Jason T. Greene wrote: >> Yes that would be very clear cut and easy to do. >> >>> On Nov 4, 2015, at 8:38 AM, Tristan Tarrant <ttarrant(a)redhat.com&gt; wrote: >>> >>> 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(a)redhat.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Tristan Tarrant >>> Infinispan Lead >>> JBoss, a division of Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev