[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] OCaml xenstore: max value size is configure to be 2048 bytes - consistent with C xenstore?
On Thu, Apr 27, 2017 at 03:42:09PM +0100, Ian Jackson wrote: > (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. > The suggestions make sense. And I agree it is post-4.9 material. We. > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |