[Qemu-devel] Re: [PATCH-V4 0/7] virtio-9p:Introducing security model for VirtFS

["Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>]

Andy Lutomirski wrote:
> Venkateswararao Jujjuri (JV) wrote:
>> This patch series introduces the security model for VirtFS.
>>
>> Brief description of this patch series:
>>
>> It introduces two type of security models for VirtFS.
>> They are: mapped and passthrough.
>>
>> The following is common to both security models.
>>
>> * Client's VFS determines/enforces the access control.
>>   Largely server should never return EACCESS.
>>
>> * Client sends gid/mode-bit information as part of creation only.
>>
>> Changes from V3
>> ---------------
>> o Return NULL instead of exit(1) on failure in virtio_9p_init()
>> o Capitalized sm_passthrough, sm_mappe
>> o Added handling for EINTR for read/write.
>> o Corrected default permissions for mkdir in mapped mode.
>> o Added additional error handling.
>>
>> Changes from V2
>> ---------------
>> o Removed warnings resulting from chmod/chown.
>> o Added code to fail normally if secuirty_model option is not specified.
>>
>> Changes from V1
>> ---------------
>> o Added support for chmod and chown.
>> o Used chmod/chown to set credentials instead of setuid/setgid.
>> o Fixed a bug where uid used instated of uid.
>>
>>
>> Security model: mapped
>> ----------------------
>>
>> VirtFS server(QEMU) intercepts and maps all the file object create
>> requests.
>> Files on the fileserver will be created with QEMU's user credentials
>> and the
>> client-user's credentials are stored in extended attributes.
>> During getattr() server extracts the client-user's credentials from
>> extended
>> attributes and sends to the client.
>>
>> Given that only the user space extended attributes are available to
>> regular
>> files, special files are created as regular files on the fileserver
>> and the
>> appropriate mode bits are stored in xattrs and will be extracted during
>> getattr.
>>
>> If the extended attributes are missing, server sends back the filesystem
>> stat() unaltered. This provision will make the files created on the
>> fileserver usable to client.
>>
>> Points to be considered
>>
>> * Filesystem will be VirtFS'ized. Meaning, other filesystems may not
>>  understand the credentials of the files created under this model.
> 
> How hard would it be to make this compatible with rsync's --fake-super?
>  (--fake-super already does almost what you're doing, and if you make
> the formats compatible, then rsync could be used to translate.  OTOH,

For conversion, I think one can write a very simple converter/translator tool to 
convert  VrtFS-ified file system. My main idea behind calling this out here is , generic
tools (say tools which track quotas) on the host may not interpret the meta-data 
properly.  IMO, Just for the sake of conversion, it may not be worth tying VirtFS
to rsync..as it may not give us free hand and things will be more complicated as we
enter into ACLs .

> rsyncing a VirtFS-ified filesystem to a remote --fake-super system might
> have odd side-effects.)

If it is done from the guest, things will be normal.
Even if it is done from host, as long as all the xattrs are restored back properly..
and there is no 'clash' between the name spaces we should be fine I guess.
We re using user.virtfs as the name space...and I don't think it clashes with that of rsync's.

- JV


> 
> --Andy