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

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