Ian Jackson
2008-Jan-16 17:01 UTC
[Xen-devel] [PATCH] disable lomount and miniterm by default
lomount is a tool which reads and parses a partition table in a disk image block device and then uses mount -o ...offset=... to mount it. This is not an ideal approach. For example, if the intended filesystem has corrupted metadata the kernel''s filesystem driver may start to write outside of the intended region. This might even be exploitable in some perverse circumstances. Nowadays people wanting to do this should use kpartx, which uses devmapper to create appropriate range mappings. So lomount should be disabled. miniterm may well be useful but it is a clone-and-hack of an upstream project and is currently built but not installed by default, partly because it doesn''t make sense to install on the dom0 which it might be trying to debug. It is probably useful to retain these two programs in the source tree but IMO they should no longer be built by default. The attached patch does these things: * CONFIG_LOMOUNT and CONFIG_MINITERM in Config.mk can enable and disable these programs * They are disabled by default * If CONFIG_MINITERM=y it is still built but not installed. make -C tools/misc/miniterm install will install it. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2008-Jan-16 17:11 UTC
Re: [Xen-devel] [PATCH] disable lomount and miniterm by default
On Wed, Jan 16, 2008 at 05:01:32PM +0000, Ian Jackson wrote: Content-Description: message body text> lomount is a tool which reads and parses a partition table in a disk > image block device and then uses mount -o ...offset=... to mount it. > This is not an ideal approach. For example, if the intended > filesystem has corrupted metadata the kernel''s filesystem driver may > start to write outside of the intended region. This might even be > exploitable in some perverse circumstances. > > Nowadays people wanting to do this should use kpartx, which uses > devmapper to create appropriate range mappings. So lomount should be > disabled.+1 for this.> miniterm may well be useful but it is a clone-and-hack of an upstream > project and is currently built but not installed by default, partly > because it doesn''t make sense to install on the dom0 which it might be > trying to debug.Any idea of what the changes are wrt to upstream ? If they''re useful we should try and get them upstream. While on the subject of tools, I''m puzelled why Xen has created custom tools qcow-create, qcow2raw and img2qcow, when they are less functional than the existing ''qemu-img'' tool that comes as part of the QEMU codebase Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2008-Jan-17 16:12 UTC
Re: [Xen-devel] [PATCH] disable lomount and miniterm by default
Daniel P. Berrange writes ("Re: [Xen-devel] [PATCH] disable lomount and miniterm by default"):> On Wed, Jan 16, 2008 at 05:01:32PM +0000, Ian Jackson wrote: > > miniterm may well be useful but it is a clone-and-hack of an upstream > > project and is currently built but not installed by default, partly > > because it doesn''t make sense to install on the dom0 which it might be > > trying to debug. > > Any idea of what the changes are wrt to upstream ? If they''re useful > we should try and get them upstream.The original author wrote it as example code for a book, rather than as a software project which might be generally distributed and updated. The internet seems full of a huge variety of clone-and-hack copies of miniterm as a result.> While on the subject of tools, I''m puzelled why Xen has created custom tools > qcow-create, qcow2raw and img2qcow, when they are less functional than > the existing ''qemu-img'' tool that comes as part of the QEMU codebaseI''m afraid this is far from clear. If no-one knows why then we should arrange to build qemu-img and and replace the references, so we can deprecate our own less-sane tools. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel