On Wed, Aug 24, 2016 at 06:41:45PM +0200, Greg Kurz wrote: > On Wed, 24 Aug 2016 18:46:10 +0300 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Wed, Aug 24, 2016 at 04:00:24PM +0100, Peter Maydell wrote: > > > On 24 August 2016 at 15:29, Greg Kurz <gr...@kaod.org> wrote: > > > > At various places in 9pfs, full paths are created by concatenating a > > > > guest > > > > originated string to the export path. A malicious guest could forge a > > > > relative path and access files outside the export path. > > > > > > > > A tentative fix was sent recently by Prasad J Pandit, but it was only > > > > focused on the local backend and did not get a positive review. This > > > > patch > > > > tries to address the issue more globally, based on the official 9P spec. > > > > > > > > The walk request described in the 9P spec [1] clearly shows that the > > > > client > > > > is supposed to send individual path components: the official linux > > > > client > > > > never sends portions of path containing the / character for example. > > > > > > > > Moreover, the 9P spec [2] also states that a system can decide to > > > > restrict > > > > the set of supported characters used in path components, with an > > > > explicit > > > > mention "to remove slashes from name components". > > > > > > > > This patch introduces a new name_has_illegal_characters() helper that > > > > looks > > > > for such unwanted characters in strings sent by the client. Since 9pfs > > > > is > > > > only supported on linux hosts, only the / character is checked at the > > > > moment. When support for other hosts (AKA. win32) is added, other chars > > > > may need to be blacklisted as well. > > > > > > Do we also need ".." and "." to be illegal names (for at least most > > > operations)? > > > > > > thanks > > > -- PMM > > > > I agree, and I think this implies name_is_legal would be a better function > > name. > > > > No I think this is a different issue that calls for a followup patch (see my > other mail).
OK, that's fine. -- MST
