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

A WFCORE JIRA for Tristan's specific request would be good. I don't think the discussion on this thread is close enough to a consensus on how to practically use this data in handling deployment ops for it to be useful to bring that aspect into a JIRA. On 11/23/15 4:13 AM, Lin Gao wrote: > >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 >