Description of problem: int and short values are overflown[1] before they even reach the business code, allowing for wrong values to be set. Version-Release number of selected component (if applicable): 3.3 is10 How reproducible: 100% Steps to Reproduce: SCENARIO A: updating the MTU in a network 1. create a network 2. issue a GET on it, check the MTU value: e.g.. from my setup: GET http://localhost:8080/api/networks/55428913-5d70-4966-9725-c2e0ed617538/ returns network href="/api/networks/55428913-5d70-4966-9725-c2e0ed617538" id="55428913-5d70-4966-9725-c2e0ed617538"> <name>ovirtmgmt</name> <description>Management Network</description> <data_center href="/api/datacenters/0a1a3010-ce0d-4342-b93e-7e32ae2f93ed" id="0a1a3010-ce0d-4342-b93e-7e32ae2f93ed" /> <stp>false</stp> <mtu>0</mtu> <usages> <usage>vm</usage> </usages> </network> 3. Issue a post that changes MTU with MTU=2*MAX_INT+100: e.g., POST http://localhost:8080/api/networks/55428913-5d70-4966-9725-c2e0ed617538/ with the body: <network> <mtu>4294967394</mtu> </network> 4. Issue a GET request and you'll see the MTU is overflown and set to 98 GET http://localhost:8080/api/networks/55428913-5d70-4966-9725-c2e0ed617538/ <network href="/api/networks/55428913-5d70-4966-9725-c2e0ed617538" id="55428913-5d70-4966-9725-c2e0ed617538"> <name>ovirtmgmt</name> <description>Management Network</description> <data_center href="/api/datacenters/0a1a3010-ce0d-4342-b93e-7e32ae2f93ed" id="0a1a3010-ce0d-4342-b93e-7e32ae2f93ed" /> <stp>false</stp> <mtu>98</mtu> <usages> <usage>vm</usage> </usages> </network> Actual results: MTU is overflown Expected results: MTU should not be overflown, and the POST should fail with a validation error. Additional info:
Note: this issue is not specific to network's MTU - it reproduces on any int/short, e.g., nfs_retrans (see bug 962442).
Alon, did you saw my comment [1]? you can also use "Restrictions on Numeric Data Types" in the schema, so i'm not sure there anything should be done. [1] https://bugzilla.redhat.com/show_bug.cgi?id=962442#c14
(In reply to Michael Pasternak from comment #2) > Alon, > > did you saw my comment [1]? you can also use "Restrictions on Numeric Data > Types" > in the schema, so i'm not sure there anything should be done. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=962442#c14 Yup, we had a little race here - this was opened as per Barak's comment 13 on bug 962442. By "Restrictions on Numeric Data Types" do you mean specificing type="xsd:unsignedInt" or something of that sort (which is already in place), or minValue/maxValue?
(In reply to Allon Mureinik from comment #3) > (In reply to Michael Pasternak from comment #2) > > Alon, > > > > did you saw my comment [1]? you can also use "Restrictions on Numeric Data > > Types" > > in the schema, so i'm not sure there anything should be done. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=962442#c14 > Yup, we had a little race here - this was opened as per Barak's comment 13 > on bug > 962442. > By "Restrictions on Numeric Data Types" do you mean specificing > type="xsd:unsignedInt" or something of that sort (which is already in > place), or minValue/maxValue? i believe w3s should have definition for "Restrictions on Numeric Data Types"
Alon, you should be using xml spec [1] to limit numbers in api.xsd [1] http://www.w3schools.com/schema/schema_dtypes_numeric.asp <xs:element name="mtu"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="..."/> </xs:restriction> </xs:simpleType> </xs:element>
According to Blaise Doughan, the JAXB (JSR-222) specification does not cover generating fail fast logic into the domain model. A common practice now is to express validation rules in the form of annotations (or XML) and run validation on them, But this is currently not part of the JSR and is being proposed as an enhancement to the JAXB reference implementation.
Ravi, can you please dedicate some time to investigate if there is any generic way to solve this issue?
All referenced patches have been merged. shouldn't this be in modified?
Verified. Got error message for values higher then limit. int: curl -k -X PUT -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Filter: $filter" -d "<network id=\"00000000-0000-0000-0000-000000000009\"><mtu>2147483648</mtu></network>" -u $ADMIN $URL/networks/00000000-0000-0000-0000-000000000009 <?xml version="1.0" encoding="UTF-8" standalone="yes"?><fault><reason>Invalid Value</reason><detail>Value 2147483648 is greater than maximum integer 2147483647</detail></fault> short: curl -k -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Filter: $filter" -d "<storage_domain><name>sd_test</name><type>data</type><storage><nfs_timeo>730</nfs_timeo><type>nfs</type><nfs_retrans>131077</nfs_retrans><address>10.34.63.199</address><path>om03</path><nfs_version>v3</nfs_version> <host><name>10.34.63.102</name></host></storage_domain>" -u $U $URL/storagedomains <?xml version="1.0" encoding="UTF-8" standalone="yes"?><fault><reason>Invalid Value</reason><detail>Value 131077 is greater than maximum unsigned short 65535</detail></fault>
Ravi, please see the verification failure on bug 962442 - seems like this issue was only partially solved. Verified on av2: Succeeded on a positive value <storage_domain> <name>test_148670_oor_retrans</name> <type>data</type> <storage> <address>10.35.160.108</address> <path>/RHEV/mbourvin1</path> <nfs_timeo>730</nfs_timeo> <nfs_retrans>65533</nfs_retrans> <nfs_version>v3</nfs_version> <type>nfs</type> </storage> <host> <name>green-vdsb</name> </host> <storage_format>v3</storage_format> </storage_domain> <fault> <reason>Operation Failed</reason> <detail> [NFS Retransmissions should be between 0 and 32767] </detail> </fault> Failed on a negative value: (Succeeded creating the storage domain although it should fail!) <storage_domain> <name>test_148670_oor_retrans</name> <type>data</type> <storage> <address>10.35.160.108</address> <path>/RHEV/mbourvin1</path> <nfs_timeo>730</nfs_timeo> <nfs_retrans>-65534</nfs_retrans> <nfs_version>v3</nfs_version> <type>nfs</type> </storage> <host> <name>green-vdsb</name> </host> <storage_format>v3</storage_format> </storage_domain> <storage_domain href= "/api/storagedomains/fc04227c-21fe-4b94-bdd2-034b9e3c6835" id="fc04227c-21fe-4b94-bdd2-034b9e3c6835"> <name>test_148670_oor_retrans</name> <link href= "/api/storagedomains/fc04227c-21fe-4b94-bdd2-034b9e3c6835/permissions" rel="permissions"/> <link href= "/api/storagedomains/fc04227c-21fe-4b94-bdd2-034b9e3c6835/disks" rel="disks"/> <link href= "/api/storagedomains/fc04227c-21fe-4b94-bdd2-034b9e3c6835/storageconnections" rel="storageconnections"/> <type>data</type> <status> <state>unknown</state> </status> <master>false</master> <storage> <address>10.35.160.108</address> <type>nfs</type> <path>/RHEV/mbourvin1</path> <nfs_version>v3</nfs_version> <nfs_timeo>730</nfs_timeo> <nfs_retrans>2</nfs_retrans> </storage> <available>2028298305536</available> <used>134217728000</used> <committed>0</committed> <storage_format>v3</storage_format> </storage_domain>
*** Bug 962442 has been marked as a duplicate of this bug. ***
Negative value OK. curl -k -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Filter: $filter" -d "<storage_domain><name>sd_test</name><type>data</type><storage><nfs_timeo>-16</nfs_timeo><type>nfs</type><nfs_retrans>-32</nfs_retrans><address>$SD</address><path>$PTH</path><nfs_version>v3</nfs_version> <host><name>$HOST</name></host></storage_domain>" -u $U $URL/storagedomains <?xml version="1.0" encoding="UTF-8" standalone="yes"?><fault><reason>Invalid Value</reason><detail>Negative value -16 not allowed for unsigned shorts, valid values are between 0 and 65535</detail></fault>
Closing as part of 3.4.0