Per the typical use of libvirt is to fork the qemu process with qemu:qemu. Setting the pool permission mode as 0700 by default will prevent the guest start with permission reason. Define macro for the default pool and vol permission modes incidentally. --- src/conf/storage_conf.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index bf4567f..6d4987b 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -47,6 +47,8 @@ #define VIR_FROM_THIS VIR_FROM_STORAGE +#define DEFAULT_POOL_PERM_MODE 0711 +#define DEFAULT_VOL_PERM_MODE 0600

VIR_ENUM_IMPL(virStoragePool, VIR_STORAGE_POOL_LAST, @@ -812,7 +814,8 @@ virStoragePoolDefParseXML(xmlXPathContextPtr ctxt) { goto cleanup; if (virStorageDefParsePerms(ctxt, &ret->target.perms, - "./target/permissions", 0700) < 0) + "./target/permissions", + DEFAULT_POOL_PERM_MODE) < 0)

On 2012年06月19日 00:24, Eric Blake wrote: > On 06/18/2012 03:47 AM, Osier Yang wrote: >> Per the typical use of libvirt is to fork the qemu process with >> qemu:qemu. Setting the pool permission mode as 0700 by default >> will prevent the guest start with permission reason. >> >> Define macro for the default pool and vol permission modes >> incidentally. >> --- >> src/conf/storage_conf.c | 11 ++++++++--- >> 1 files changed, 8 insertions(+), 3 deletions(-) >> >> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c >> index bf4567f..6d4987b 100644 >> --- a/src/conf/storage_conf.c >> +++ b/src/conf/storage_conf.c >> @@ -47,6 +47,8 @@ >> >> #define VIR_FROM_THIS VIR_FROM_STORAGE >> >> +#define DEFAULT_POOL_PERM_MODE 0711 >> +#define DEFAULT_VOL_PERM_MODE 0600 > > Isn't 755 more typical than 711 for directory permissions? For that > reason, I'd like a second opinion on whether the more relaxed > permissions make sense. The difference is 755 allows the group users and others to inspect what the images are and their permissions in the pool. The side effect what I can think of is: % ls -l /var/lib/libvirt/images/ -rw-r--r--. 1 root root 1048576 6月 18 14:34 attch.img -rw-r--r--. 1 root root 1048576 6月 14 17:38 foo2.img -rw-r--r--. 1 root root 1048576 6月 14 17:33 foo.img -rw-rw-rw-. 1 root root 0 6月 21 11:31 local.img % > /var/lib/libvirt/images/local.img I.e, if one can check the files in the pool, and the vols have write permission for group users/others exposed, then it can be easily damaged. However, one can destroy the vols data anyway even with 711, though one should known the filename of the target vol first, e.g. % ls -ld /var/lib/libvirt/images/ drwx--x--x. 2 root root 4096 Jun 18 14:34 /var/lib/libvirt/images/ % stat /var/lib/libvirt/images/local.img File: `/var/lib/libvirt/images/local.img' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 808h/2056d Inode: 1054167 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:virt_image_t:s0 Access: 2012-06-21 11:39:41.928284645 +0800 Modify: 2012-06-21 11:31:11.948457979 +0800 Change: 2012-06-21 11:38:58.948639333 +0800 Birth: - % > /var/lib/libvirt/images/local.img % So from my p.o.v, 711 is better choice, at least it's not that easy for the group users/others to get the file names in the pool. Regards, Osier -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 06/21/12 05:49, Osier Yang wrote: > On 2012年06月19日 00:24, Eric Blake wrote: >> On 06/18/2012 03:47 AM, Osier Yang wrote: >>> Per the typical use of libvirt is to fork the qemu process with >>> qemu:qemu. Setting the pool permission mode as 0700 by default >>> will prevent the guest start with permission reason. >>> >>> Define macro for the default pool and vol permission modes >>> incidentally. >>> --- >>> src/conf/storage_conf.c | 11 ++++++++--- >>> 1 files changed, 8 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c >>> index bf4567f..6d4987b 100644 >>> --- a/src/conf/storage_conf.c >>> +++ b/src/conf/storage_conf.c >>> @@ -47,6 +47,8 @@ >>> >>> #define VIR_FROM_THIS VIR_FROM_STORAGE >>> >>> +#define DEFAULT_POOL_PERM_MODE 0711 >>> +#define DEFAULT_VOL_PERM_MODE 0600 >> >> Isn't 755 more typical than 711 for directory permissions? For that >> reason, I'd like a second opinion on whether the more relaxed >> permissions make sense. > > The difference is 755 allows the group users and others to inspect > what the images are and their permissions in the pool. The side > effect what I can think of is: > > % ls -l /var/lib/libvirt/images/ > > -rw-r--r--. 1 root root 1048576 6月 18 14:34 attch.img > -rw-r--r--. 1 root root 1048576 6月 14 17:38 foo2.img > -rw-r--r--. 1 root root 1048576 6月 14 17:33 foo.img > -rw-rw-rw-. 1 root root 0 6月 21 11:31 local.img > > % > /var/lib/libvirt/images/local.img > > I.e, if one can check the files in the pool, and the vols > have write permission for group users/others exposed, then > it can be easily damaged. > > However, one can destroy the vols data anyway even with 711, > though one should known the filename of the target vol first, > e.g. By not allowing to view the directory contents you don't really add much security. I don't like security-by-obscurity approaches. IIUC you are able to change the permissions on the pool if you wish to have different from the default, so this choice should just > > % ls -ld /var/lib/libvirt/images/ > drwx--x--x. 2 root root 4096 Jun 18 14:34 /var/lib/libvirt/images/ > % stat /var/lib/libvirt/images/local.img > File: `/var/lib/libvirt/images/local.img' > Size: 0 Blocks: 0 IO Block: 4096 regular empty > file > Device: 808h/2056d Inode: 1054167 Links: 1 > Access: (0666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) > Context: system_u:object_r:virt_image_t:s0 > Access: 2012-06-21 11:39:41.928284645 +0800 > Modify: 2012-06-21 11:31:11.948457979 +0800 > Change: 2012-06-21 11:38:58.948639333 +0800 > Birth: - > % > /var/lib/libvirt/images/local.img > % > > So from my p.o.v, 711 is better choice, at least it's not that > easy for the group users/others to get the file names in the > pool. I vote for the more common 755 permissions. We shouldn't try to hide the real problem if permissions are misconfigured by hiding the names.