Re: [Qemu-devel] [PATCH] 9pfs: disallow / in path components

[Peter Maydell]

On 24 August 2016 at 17:40, Greg Kurz <address@hidden> wrote:
> On Wed, 24 Aug 2016 16:00:24 +0100
> Peter Maydell <address@hidden> wrote:
>> Do we also need ".." and "." to be illegal names (for at least most
>> operations)?

> I understand how ".." could be an issue, but I don't for "."... can you
> please elaborate ?

If you try to create, open, etc a file named "." then it won't create a
file named "."; it'll do something wrong instead. So we shouldn't
permit attempts to treat "." as an ordinary filename.

(Basically the rationale is that for Linux the constraints on
file and pathnames are only
 * no NULs
 * no /
 * "." is special
 * ".." is special
 * can't be the empty string
We should reflect that in our error checking.)

> The spec says:
>
>           Directories are created by create with DMDIR set in the per-
>           missions argument (see stat(5)). The members of a directory
>           can be found with read(5). All directories must support
>           walks to the directory .. (dot-dot) meaning parent direc-
>           tory, although by convention directories contain no explicit
>           entry for .. or . (dot).  The parent of the root directory
>           of a server's tree is itself.

Yes, walk is the one special case that needs to handle "." and ".."
(because for this operation they have a defined meaning that doesn't
mean "just pass them through to the libc functions").

> So I don't think we should boldly make ".." an illegal name, but
> rather ignore it. Pretty much like doing chdir("..") when the current
> directory is /.
>
> All operations except walk take an existing fid and a single path component.
> A possible fix would be to convert ".." to "" when the fid points to the root
> of the export path. Makes sense ?

What did you want the empty string to mean? (We should probably
also define the empty string as an illegal name).

thanks
-- PMM