qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] tools/virtiofsd: xattr name mappings: Add option


From: Stefan Hajnoczi
Subject: Re: [PATCH 1/3] tools/virtiofsd: xattr name mappings: Add option
Date: Wed, 5 Aug 2020 13:47:49 +0100

On Mon, Aug 03, 2020 at 08:15:09PM +0100, Dr. David Alan Gilbert (git) wrote:
> diff --git a/docs/tools/virtiofsd.rst b/docs/tools/virtiofsd.rst
> index 824e713491..82b6f6d90a 100644
> --- a/docs/tools/virtiofsd.rst
> +++ b/docs/tools/virtiofsd.rst
> @@ -107,6 +107,51 @@ Options
>    performance.  ``auto`` acts similar to NFS with a 1 second metadata cache
>    timeout.  ``always`` sets a long cache lifetime at the expense of 
> coherency.
>  
> +xattr-mapping
> +-------------
> +
> +By default the name of xattr's used by the client are passe through to the 
> host
> +file system.  This can be a problem where either those xattr names are used
> +by something on the host (e.g. selinux guest/host confusion) or if the
> +virtiofsd is running in a container with restricted priviliges where it 
> cannot
> +access some attributes.
> +
> +A mapping of xattr names can be made using -o xattrmap=mapping where the 
> ``mapping``
> +string consists of a series of rules.
> +
> +Each rule starts and ends with a ':'.  The mapping stops on a matching
> +rule.  White space may be added before and after each rule.
> +
> +:scope:type:key:prepend:
> +
> +scope= 'c' - match 'key' against a xattr name from the client
> +            for setxattr/getxattr/removexattr
> +       'h' - match 'prepend' against a xattr name from the host
> +            for listxattr
> +       both letters can be included to match both cases.
> +
> +type is one of:
> +       'p' Prefixing: If 'key' matches the client then the 'prepend'
> +           is added before the name is passed to the host.
> +           For a host case, the prepend is tested and stripped
> +           if matching.
> +
> +       'o' OK: The attribute name is OK and passed through to
> +           the host unchanged.
> +
> +       'b' Bad: If a client tries to use this name it's
> +           denied using EPERM; when the host passes an attribute
> +           name matching it's hidden.
> +
> +key is a string tested as a prefix on an attribute name originating
> +       on the client.  It maybe empty in which case a 'c' rule
> +       will always match on client names.
> +
> +prepend is a string tested as a prefix on an attribute name originiating
> +       on the host, and used as a new prefix by 'p'.  It maybe empty
> +       in which case a 'h' rule will always match on host names.

This syntax and the documentation is hard to understand. Defining
concrete commands instead of a single super-command would make it more
straightforward.

Here is the functionality I've been able to extract from the
documentation:

1. Rewrite client xattrs

   rewrite OLD NEW -> s/^OLD/NEW/

2. Allow client xattrs

   allow PREFIX -> allow if matching

3. Deny client xattrs

   deny PREFIX -> EPERM if matching

4. Unprefix server xattrs

   unprefix PREFIX -> s/^PREFIX//

5. Hide server xattrs

   hide PREFIX -> skip if matching

Did I miss any functionality?

I suggest using "client" and "server" terminology instead of "client"
and "host".

Prefix syntax: xattr names are matched by prefix. The empty string
matches all xattr names. How is ':' escaped?

It is unclear whether 'o' terminates processing immediately. Will later
'p' rules still execute?

It is unclear whether 'o'/'b' match the original client name or the
rewritten name after a 'p' command.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]