[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] OCaml xenstore: max value size is configure to be 2048 bytes - consistent with C xenstore?
(dropping Lars; CCing MAINTAINERs for affected areas.) Christian Lindig writes ("OCaml xenstore: max value size is configure to be 2048 bytes - consistent with C xenstore?"): > We recently had a case where XenServer installation showed errors because the > data stored in OCaml xenstore exceeded 2048 bytes: > > [root@dt87 tmp]# xenstore-write /local/domain/1/foo $(cat /dev/zero | tr '\0' > X | dd bs=1 count=2048) > 2048+0 records in > 2048+0 records out > 2048 bytes (2.0 kB) copied, 0.00743674 s, 275 kB/s > [root@dt87 tmp]# xenstore-write /local/domain/1/foo $(cat /dev/zero | tr '\0' > X | dd bs=1 count=2049) > 2049+0 records in > 2049+0 records out > 2049 bytes (2.0 kB) copied, 0.00714459 s, 287 kB/s > xenstore-write: could not write path /local/domain/1/foo (xenstore-write is erroneously failing to print errno here, but code inspection shows that it would be E2BIG.) > This limit is configured in quota-maxsize: > > https://github.com/mirage/xen/blob/master/tools/ocaml/xenstored/oxenstored.conf.in#L50 > > This could be a surprise because in quota.ml it is initialised to 4096 and > later reset when the config file is read. That's quite odd. > https://github.com/mirage/xen/blob/master/tools/ocaml/xenstored/quota.ml#L24 > > My questions: is this behaviour consistent with the C xenstore implementation > and if not, should this be documented or changed? Should the OCaml > implementation made more consistent by using the 2048 for the initial value? It's not consistent. The C implementation does not have this limit. It has these limits, though: 4096 bytes of total command payload (ie length of a command or response, in the ring, excluding the ring header) 3072 bytes absolute pathname 2048 bytes relative pathname This seems like it would allow a guest to create a data node which could not be updated by the toolstack domain - because the guest could use a relative path, but the toolstack domain would have to use an absolute path. (It can be read by the toolstack domain because when reading, the pathname does not need to be specified in the reply; and of course it can easily be deleted. So I don't think there are security problems here.) I think we should probably impose a limit in the C xenstored which prevents such a situation. I'm not sure that the value of 2048 is right, though. A guest could write a 2048-byte data item at a 2048-byte relative path, and this would have the same problem. Thinking about this some more I suggest we: * reduce the relative pathname limit to 1536 bytes * impose a 2048-byte per-node-data length limit in the C xenstored * change the compiled-in 4096-byte per-node-data limit in the Ocaml xenstored to 2048 bytes What do people think ? Whatever we do this should probably be post-4.9. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |