[Kimchi-devel] [PATCH] Set virt_use_nfs when NFS pool is added.

[Christy Perez]

On Thu, 2014-04-03 at 10:22 +0800, Royce Lv wrote:
> On 2014年04月03日 03:40, Aline Manera wrote:
> > On 04/01/2014 03:24 AM, Royce Lv wrote:
> >> On 2014年03月29日 05:20, Christy Perez wrote:
> >>> selinux has a special boolean to make it easier for disk images
> >>> to be stored on a remote NFS server. Set this to true when a user
> >>> adds an NFS storage pool.
> >>>
> >>> Most virtualzation documentation recommends that this be set
> >>> to true. For example:
> >>> http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues
> >>> http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems
> >>>
> >>> This will leave it set to true, even if
> >>> the user removes NFS storage pools. It is not a security risk, and
> >>> we should not set it to False in case it had already been set by the
> >>> user for another non-kimchi use.
> >>>
> >>> Signed-off-by: Christy Perez <christy at linux.vnet.ibm.com>
> >>> ---
> >>>   src/kimchi/i18n.py               | 2 ++
> >>>   src/kimchi/model/storagepools.py | 5 +++++
> >>>   2 files changed, 7 insertions(+)
> >>>
> >>> diff --git a/src/kimchi/i18n.py b/src/kimchi/i18n.py
> >>> index d45f607..8ade7d7 100644
> >>> --- a/src/kimchi/i18n.py
> >>> +++ b/src/kimchi/i18n.py
> >>> @@ -144,6 +144,8 @@ messages = {
> >>>       "KCHPOOL0034E": _("Unable to deactivate pool %(name)s as it is 
> >>> associated with some templates"),
> >>>       "KCHPOOL0035E": _("Unable to delete pool %(name)s as it is 
> >>> associated with some templates"),
> >>>       "KCHPOOL0036E": _("A volume group named '%(name)s' already 
> >>> exists. Please, choose another name to create the logical pool."),
> >>> +    "KCHPOOL0037E": _("Unable to set selinux bool virt_use_nfs for 
> >>> NFS pool usage. Depending on \
> >>> +                       your NFS config, this may prevent the pool 
> >>> from being used."),
> >>>
> >>>       "KCHVOL0001E": _("Storage volume %(name)s already exists"),
> >>>       "KCHVOL0002E": _("Storage volume %(name)s does not exist in 
> >>> storage pool %(pool)s"),
> >>> diff --git a/src/kimchi/model/storagepools.py 
> >>> b/src/kimchi/model/storagepools.py
> >>> index 92b2496..d279ffa 100644
> >>> --- a/src/kimchi/model/storagepools.py
> >>> +++ b/src/kimchi/model/storagepools.py
> >>> @@ -126,6 +126,11 @@ class StoragePoolsModel(object):
> >>>               kimchi_log.error("Problem creating Storage Pool: %s", e)
> >>>               raise OperationFailed("KCHPOOL0007E",
> >>>                                     {'name': name, 'err': 
> >>> e.get_error_message()})
> >>> +        if params['type'] == 'netfs':
> >>> +            output, error, returncode = run_command(['setsebool', 
> >>> '-P',
> >>> + 'virt_use_nfs=1'])
> >> 1. what about turn this on when start kimchi? Cause we just need to 
> >> enable this for the first time.
> >
> > I don't think it is good.
> > If we modify it only on Kimchi startup and user or other application 
> > revert our changes - the user will not be able to create the NFS pool
> Well, then what if other users change the firewall configuration? We 
> still cannot access kimchi through browser. And I can't find a reason 
> why user will intensionally toggle this off.
> I can accept this if you think this is safer, still we need to handle 
> versions despite fedora/rhel.
> >
> >> 2. For Debian using apparmor, it does not have setsebool, I think 
> >> this need to be handled too.
If a debian distro is using AppArmor, it won't be an issue like it is
with SELinux. AppArmor is FS agnostic (see
http://www.ibm.com/developerworks/security/library/l-selinux/index.html). So, I think that we can safely catch an exception here if there's no SELinux. If AppArmor is enabled instead of SELinux we don't need to do anything NFS-specific for libvirt.

Does that address your concern?

> >>> +            if error or returncode:
> >>> +                kimchi_log.error('KCHPOOL0037E')
> >>>           return name
> >>>
> >>>       def _clean_scan(self, pool_name):
> >>
> >> _______________________________________________
> >> Kimchi-devel mailing list
> >> Kimchi-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> >
>