Re: [V9fs-users] v9fs howto?

[Venkateswararao J. (JV) <jv...@li...>]

On 1/24/2011 10:17 AM, Rob Landley wrote:
> On 01/24/2011 11:09 AM, Venkateswararao Jujjuri (JV) wrote:
>> On 1/24/2011 6:44 AM, Eric Van Hensbergen wrote:
>>> On Sun, Jan 23, 2011 at 1:13 PM, Rob Landley <rla...@pa...> wrote:
>>>> Is there any documentation that covers how to export a directory via p9
>>>> and mount it somewhere else, through standard ipv4?
>>>>
>>>
>>> I'll start off by saying that I'm the maintainer of the Linux client
>>> and not directly
>>> involved with the development of any of the servers -- however, I'll
>>> do my best to
>>> answer your questions.
>>>
>>> Over standard ipv4, you'll need one of the many servers.  There is a
>>> comprehensive
>>> list here: http://9p.cat-v.org/implementations
>>>
>>> If you are going Linux<->Linux then I suggest you grab spfs/npfs --
>>> you'll want to
>>> use the source repo:
>>>    svn co https://npfs.svn.sourceforge.net/svnroot/npfs npfs
>>>
>>> Once you've grabbed that, build the spfs version for simplicity (it
>>> gives 9p2000.u):
>>>    % cd npfs/spfs/trunk
>>>    % make
>>>
>>> Then go ahead and start a simple file server which will access files
>>> on the server
>>> with the credentials of whoever starts the server:
>>>   % cd fs
>>>   % ./ufs -s -p 5670
>>>
>>> (This starts the server on port 5670 so you can run it as a normal user).
>>>
>>> Then you can do the mount from the client:
>>>   mount -t 9p server.ip.address /mnt -o port=5670
>>>
>>> and you should be able to access files.
>>>
>>>> I found http://wiki.qemu.org/Documentation/9psetup and managed to do a
>>>> read-only mount, but when I attempt to write to the mount point the
>>>> files don't get created and it errors out.  (Dunno if this is a bug or
>>>> an imcomplete server in qemu-git.)
>>
>> I would assume that you tried this in the KVM environment over VirtIO.
> 
> I used, qemu-system-x86_64 built from saturday's git pull.  I can't
> quite seem to get it to use the kvm extensions, even though my Ubuntu
> shipped with a kvm binary that works fine, but it runs ok as qemu.

Then you should have quite up-to-date VirtFS Server.

> 
>> You may run into situation like this(read-only) if SELinux is enabled on the guest.
> 
> I don't think selinux is left enabled in any system I ever use for
> anything, but just to be sure I removed the CONFIG_SECURITY_SELINUX from
> the kernel I'm booting under KVM and tried again.  It made no
> difference.  The mount can read, but not write.
> 
> I confirmed that the directory I'm exporting is owned by the user who's
> running kvm.
> 
> However, what fixed it was Eric's suggestion of switching the security
> model to none:
> 
>   -virtfs local,security_model=none,mount_tag=kvm,path=/blah/9ptest

Ah. That makes sense. We have 3 security models.  passthrough, mapped and none.
Here is some brief description about these models.

Access mode: mapped
--------------------

Fileserver intercepts and maps all the file object create requests.
Files on the fileserver will be created with Fileserver'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.

This adds a great deal of security in the cloud environments where the
guest's(client) user space is kept completely isolated from host's user
space.

QEMU can be started as any regular user.

Access mode : passthrough
--------------------------

In this security model, Fileserver passes down all requests to the
underlying filesystem. File system objects on the fileserver will be created
with client-user's credentials. This is done by setting setuid()/setgid()
during creation or chmod/chown after file creation. At the end of create
protocol
request, files on the fileserver will be owned by cleint-user's uid/gid.
This model mimic's current NFSv3 level of security.

This needs QEMU running under root.

Access mode: NONE
--------------------

In 'NONE' mode, the (filesystem) server attempts to preserve user/group
ownership from guest, however:
- If the server is running as root this mode is equivalent to passthrough.
- If the server is running as non-root, all files just have uid/gid matching
   the server process.




> 
> Apparently, security_model=passthrough silently fails on writes for me.
>  (Do I need to be running KVM as root for it to work?)

Yes.. QEMU needs to be running as root.

> 
> Presumably, this is expected without passthrough:
> 
>   root@kvm:~/woot# cp -a /dev/zero zero
>   cp: cannot create special file `zero': Operation not permitted
> 
> I'm doing:
> 
>   mount -t 9p -o trans=virtio,version=9p2000.L kvm woot
> 
> (Do I really need to say verson?  I thought it autodetected it...)

You need to specify the version. For now the default is 9P2000.u.
Once dotl becomes stable, plan is to make it default.

Thanks,
JV

> 
> Rob