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?

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

On 3 Nov 2015, at 14:19, David M. Lloyd wrote: > I'm pretty sure that if an attacker has permission to upload deployments > to the server, they already essentially have control over the server. Well, uploads can be remotely, so this can be seen as a DOS attack vector that does not necessarily require privileges for (physical) access like (remote) shell.

And then I recall there being the zip bombs where a very small file would unzip to a huge one. This is probably nothing that could be caught by limiting the size of the upload.

> You can try to down the server with a DOS like this:

On 3 Nov 2015, at 14:19, David M. Lloyd wrote: > I'm pretty sure that if an attacker has permission to upload deployments > to the server, they already essentially have control over the server. Well, uploads can be remotely, so this can be seen as a DOS attack vector that does not necessarily require privileges for (physical) access like (remote) shell. And then I recall there being the zip bombs where a very small file would unzip to a huge one. This is probably nothing that could be caught by limiting the size of the upload. Do we know if WF continues to work when e.g. the partition for log files or other data is full? -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)jboss.com <mailto:darran.lofthouse@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

GWT boils down to plain web technologies. And no, AFAIKT there is no way to check the size of an uploaded file across web browsers. Most browsers do however have an implicit limitation on the file size, which for majority is about 2 GB. > On 04 Nov 2015, at 10:11, Darran Lofthouse <darran.lofthouse(a)jboss.com > <mailto:darran.lofthouse@jboss.com>> wrote: > > From within GWT is there any option to detect the file size before > uploading?

On Nov 4, 2015, at 4:36 AM, Heiko Braun <hbraun(a)redhat.com&gt; wrote: GWT boils down to plain web technologies. And no, AFAIKT there is no way to check the size of an uploaded file across web browsers. Most browsers do however have an implicit limitation on the file size, which for majority is about 2 GB.

> On 04 Nov 2015, at 10:11, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: > > From within GWT is there any option to detect the file size before > uploading? _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Does the op in the CLI send any length information? That would help the two be consistent. On 04/11/15 12:29, Jason T. Greene wrote: > > On Nov 4, 2015, at 4:36 AM, Heiko Braun <hbraun(a)redhat.com > <mailto:hbraun@redhat.com>> wrote: > >> GWT boils down to plain web technologies. And no, AFAIKT there is no >> way to check the size of an uploaded file across web browsers. Most >> browsers do however have an implicit limitation on the file size, >> which for majority is about 2 GB. > > You can now that we have switched to XHR to do the upload. The File > object returned from a file list has a size property that you can use. > > So you could in theory check that there is available space before > posting, however, since as Stuart mentions, browsers set a content > length, the server knows it anyway so it's less racy checking at the > server level, if one was to check. > > >> >>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote: >>> >>> From within GWT is there any option to detect the file size before >>> uploading? >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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

On Nov 4, 2015, at 8:09 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: Actually - this makes me think 'Content Length' on a HTTP upload is not a suitable measure of the file size - this is the length being sent to the server, not necessarily the actual size of the resulting file.

> On 04/11/15 14:06, Brian Stansberry wrote: > It shouldn't as part of the management API, no.[1] Any total size > information that gets exchanged is part of the underlying management > communication protocol used for propagating streams and isn't exposed > outside that layer. I'd like to see even that bit go away too, as it's > unnecessary and wastes resources on the client. > > [1] In some cases the CLI actually sends the deployment bytes base 64 > encoded as a param to the op, in which case the size info is available > to the operation step handler. I consider that CLI behavior to be a bug > though. > >> On 11/4/15 7:52 AM, Darran Lofthouse wrote: >> Does the op in the CLI send any length information? That would help the >> two be consistent. >> >>> On 04/11/15 12:29, Jason T. Greene wrote: >>> >>> On Nov 4, 2015, at 4:36 AM, Heiko Braun <hbraun(a)redhat.com >>> <mailto:hbraun@redhat.com>> wrote: >>> >>>> GWT boils down to plain web technologies. And no, AFAIKT there is no >>>> way to check the size of an uploaded file across web browsers. Most >>>> browsers do however have an implicit limitation on the file size, >>>> which for majority is about 2 GB. >>> >>> You can now that we have switched to XHR to do the upload. The File >>> object returned from a file list has a size property that you can use. >>> >>> So you could in theory check that there is available space before >>> posting, however, since as Stuart mentions, browsers set a content >>> length, the server knows it anyway so it's less racy checking at the >>> server level, if one was to check. >>> >>> >>>> >>>>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>>>> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote: >>>>> >>>>> From within GWT is there any option to detect the file size before >>>>> uploading? >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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

> From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt;

> > [1] In some cases the CLI actually sends the deployment bytes base 64 > encoded as a param to the op, in which case the size info is available > to the operation step handler. I consider that CLI behavior to be a bug > though. Do you recall which cases that the CLI will send deployment bytes instead of the input stream? :-)

>> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: "Lin Gao" <lgao(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Wednesday, November 4, 2015 9:41:36 PM Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? > On Nov 4, 2015, at 6:48 AM, Jason T. Greene <jason.greene(a)redhat.com&gt; > wrote: > > 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). One thing I forgot to get into was domain mode. Runtime verification is straight forward on standalone, but on domain mode the deployment is pulled by arbitrary hosts, which each may have varying disk capacity. So in the host case we can only error later on and after the fact. Hosts try to pull down content in the content repository (where deployments are stored) only when they need them, and this can happen well after a deployment is added. As an example, 3 weeks later you could add a server to a host that's in a server group that requires a download of a deployment, and at that point go over capacity.

On 11/30/15 8:56 PM, Lin Gao wrote: > There are 2 aspects on this issue which we need to concern I think: > > 1. How to get the size of the file which will be uploaded > > In most cases, it is possible to know the size of the uploaded file, > in web console, GWT file object has a size property, in CLI, Java codes > can get the file size by: File.length() method, but in case of CLI: > 'deploy --url=http://XXX.zip' while the url points to a resource using > chunked encoding(no Content-Length available) transfer, we don't know the > size at all when content repository starts to download. We also may not know it on the client side (CLI process) regardless of chunked encoding, as the URL is meant to be opened from the server and there is no requirement that the client be able to access it. So for this kind of deployment there is no consistent way for the CLI to check in advance that the deployment will succeed. > > 2. How to know that the disk space is enough to hold the file processing > > In web console, Undertow will store the file to system temporary directory > ('/tmp/')first, then content repository will copy it to the it's root directory > for processing. In CLI, the content repository will dump the stream to it's root > directory('data/content/') for processing. Normally, the deployer will > un-zipped the zip file to 'tmp/vfs/temp/', the size of the exploded files > will be much bigger than the zip file itself.(consider the zip bomb... ?) > > Apparently, the disk space to hold the file processing is at least more than > double the size of uploaded file. The concrete available disk space is hard to know, > and it is changing all over the time(thinking of logs). > > After reconsideration, I agree with Stuart that adding any kind of limit seems > like this has the potential to cause more problems than it will solve. :-) > > So back to the original question as $subject: Shall we limit size of the > deployment in WildFly? or do we want to continue on proceeding this issue ? > No to both questions. It's not feasible to create a robust feature.

Good analysis; thanks. > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > > ----- Original Message ----- >> From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; >> To: "Lin Gao" <lgao(a)redhat.com&gt; >> Cc: wildfly-dev(a)lists.jboss.org >> Sent: Wednesday, November 4, 2015 9:41:36 PM >> Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? >> >> >>> On Nov 4, 2015, at 6:48 AM, Jason T. Greene <jason.greene(a)redhat.com&gt; >>> wrote: >>> >>> 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). >> >> One thing I forgot to get into was domain mode. Runtime verification is >> straight forward on standalone, but on domain mode the deployment is pulled >> by arbitrary hosts, which each may have varying disk capacity. >> >> So in the host case we can only error later on and after the fact. Hosts try >> to pull down content in the content repository (where deployments are >> stored) only when they need them, and this can happen well after a >> deployment is added. As an example, 3 weeks later you could add a server to >> a host that's in a server group that requires a download of a deployment, >> and at that point go over capacity. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

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

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

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 >

Hi, Here is my ideas and questions for displaying the filesystem usage for the various paths: * create a handler like the ResolvePath handler so that it becomes really easy to add the metric to any path attribute.

* adding it per default in the PathResourceDefinition to make it widely available 'for free'.

* which unit should we use to express it ? Is bytes ok ?

* do we want to have all the values in the server-environment or are those under /path sufficient ?

* do we want to aggregate those values in a 'single' metric and if so which paths should we select ?

* for space availability this might depend on the different mount points: - should we provide it for every path since we wouldn't know in advance to which mount point each path is on

- or maybe this info is not that important Cheers, Emmanuel Le 24/11/2015 08:43, Tristan Tarrant a écrit : > https://issues.jboss.org/browse/WFCORE-1159 > > Tristan > > On 24/11/2015 00:51, Brian Stansberry wrote: >> 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 >>> >> >> > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Keeping only the relevant parts, remarks inlined : >> * for space availability this might depend on the different mount points: >> - should we provide it for every path since we wouldn't know in advance to which mount point each path is on > > I don't understand this question. How were you planning to get the space > availability information? > > My instinct is the closer this conforms to what the standard java (n)io > API provides the better. > What I mean is that since we don't know to which mount point/drive each path is using, we would have to define the space availability per path instead of as a global metric/value.

So I was wondering if this is really something that makes sense. Which explains the next question aka are these informations valuable.

>> - or maybe this info is not that important >> Cheers, Emmanuel

Le 04/12/2015 16:08, Brian Stansberry a écrit : > On 12/4/15 6:41 AM, Emmanuel Hugonnet wrote: >> Keeping only the relevant parts, remarks inlined : >> >>>> * for space availability this might depend on the different mount points: >>>> - should we provide it for every path since we wouldn't know in advance to which mount point each path is on >>> >>> I don't understand this question. How were you planning to get the space >>> availability information? >>> >>> My instinct is the closer this conforms to what the standard java (n)io >>> API provides the better. >>> >> >> What I mean is that since we don't know to which mount point/drive each path is using, we would have to define the space availability per >> path instead of as a global metric/value. > > I don't think we should try to do any kind of aggregation or analytical work. A path resolves to a File and a File reports getUsableSpace(). > If a user looks at two paths on the same partition and double counts by assuming he can use that much for each path, that's a user error. > But it's kind of a "duh" kind of error, so long as we document the semantic (including a reference to the JDK javadoc we rely upon) and are > careful about how the data is presented in any UI. The UI is probably the bigger problem. > >> So I was wondering if this is really something that makes sense. Which explains the next question aka are these informations valuable. >> > > That I don't know, but it seems useful. It provides information that a a user can then reason with, either well or poorly. It's not rocket > science to reason intelligently though. > > I rarely object to not including something that hasn't been specifically asked for though, so I don't mind not including this if no one > makes a case for it. Basically we can iterate over the filestore aka partitions/drives so we could display this info in a centralized point.

> >>>> - or maybe this info is not that important >>>> >> >> Cheers, >> Emmanuel >> > >

Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary?