[wildfly-dev] Shall we limit size of the deployment in WildFly?
Brian Stansberry
brian.stansberry at redhat.com
Mon Nov 23 18:51:28 EST 2015
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 at jboss.com>
>> To: "Jason T. Greene" <jason.greene at redhat.com>, "Tristan Tarrant" <ttarrant at redhat.com>
>> Cc: wildfly-dev at 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 at redhat.com> 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 at redhat.com> 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 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
>>>>
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of 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
>>>
>> _______________________________________________
>> 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
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list