On Mon, Oct 11, 2010 at 12:21:19PM +0530, Harsh Prateek Bora wrote: > This patch introduces new attribute to filesystem element > to support customizable security for mount type. > Valid mount_security are: passthrough and mapped. > > Usage: > <filesystem type='mount' mount_security='passthrough'> > <source dir='/export/to/guest'/> > <target dir='mount_tag'/> > </filesystem> > > Here is the detailed explanation on these security models: > > Security model: 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. > > > Security model : 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. In your first patch you had a 3rd option 'none', whose semantics I had asked about, because they appeared to be the same as passthrough. Looking at the QEMU virtio-9p.c file comments though, it appears that there is in fact a difference. - In 'passthrough' the user/group ownership is preserved from the guest requests. - In 'mapped' the guest user/group ownership is stored in xtended attrs with files on host keeping same uid/gid as the QEMU process - In 'none' the user/group ownership from guest is completely ignored, and all files just have uid/gid matching the QEMU process. If this interpretation of QEMU code is correct, then I think we should support all 3 options in libvirt after all. The 'passthrough' option should be the default in libvirt, because that matches the semantics of the <filesystem> element usage in LXC / OpenVZ drivers in libvirt. I think I'd give 'none' a different name in the XML , perhaps call it 'squash', inspired by NFS root squash, which squashes uid/gid onto a single user. Finally I'm thinking that the security attribute should be called 'accessmode' rather than 'mount_security', mostly because I don't like underscores in XML attribute/element names. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list