Re: [libvirt] [PATCH v4 1/5] Introduce virDomainRename API
On Thu, Aug 13, 2015 at 10:22:25 +0200, Tomas Meszaros wrote: Also, among with this new API new ACL that restricts rename capability is invented too. Signed-off-by: Tomas Meszaros e...@tty.sk --- include/libvirt/libvirt-domain.h | 4 src/driver-hypervisor.h | 6 ++ src/libvirt-domain.c | 35 +++ src/libvirt_public.syms | 5 + src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 18 +- src/remote_protocol-structs | 9 + 7 files changed, 77 insertions(+), 1 deletion(-) ... diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index dc89bab..9065dab 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -8774,6 +8774,41 @@ virDomainIsPersistent(virDomainPtr dom) return -1; } +/** + * virDomainRename: + * @dom: pointer to the domain object + * @new_name: new domain name + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Rename a domain. New domain name is specified in the second + * argument. Depending on each driver implementation it may be + * required that domain is in a specific state. Additionally the comment should state that certain attributes of the domain's config are not modified even if they contain the domain name. One example is the auto-generated socket path for guest agent connections. Neglecting to change it after a rename and defining a new domain with the same name as the previously renamed one will then result in problems in guest agent use. Ideally the code would rename that but IIRC the idea was rejected previously. Peter signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Fri, Aug 14, 2015 at 12:20:46PM +0200, Martin Kletzander wrote:
On Fri, Aug 14, 2015 at 11:10:05AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 14, 2015 at 11:58:54AM +0200, Martin Kletzander wrote:
On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 13, 2015 at 05:47:42PM +0200, Martin Kletzander wrote:
We are currently unable to label parent directories for some paths.
However, we will need to have per-domain directories that we would like
to have labelled, but we can't label all of them. So let's add a
boolean variable that will determine whether parent directory for such
chardev should be labelled as well as that character device itself.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/conf/domain_conf.h | 1 +
src/security/security_dac.c | 13 -
src/security/security_selinux.c | 13 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e1872bca002c..9d549a395e29 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1191,6 +1191,7 @@ struct _virDomainChrSourceDef {
} udp;
struct {
char *path;
+bool autopath;
bool listen;
} nix;
int spicevmc;
I don't think we need this - it seems we can just pass a 'bool labelParent'
parameter into virSecurityManagerSetChardevLabel() when calling it for
the monitor socket.
It's not used only for the monitor socket, but mainly for virtio
channel's target's unix socket as well and maybe more in the future.
But I agree it could be named 'labelParent' as well. Should I resend
it with that changed?
In the non-monitor cases how will we decide whether it is appropriate
to set labelParent or not ? Those paths are broadly user specified,
so we can't assume the parent is per-VM
We will label only those that we are sure that are per-VM, so only
those that are generated by the qemu driver itself. That's exactly
what the parameter is used for -- labelling parent directories only
for those paths that are auto-generated by us, but leaving all
user-specified ones alone.
IIUC, the paths generated by us will all end up in the same directory.
So if we label that directory when setting up the monitor, then it
will be correct for all the other paths too, so it doesn't seem like
we need to store this parameter in virDomainDef. In fact, I tend to
think we should perhaps add a virSecurityManagerSetDirLabel() that
we just invoke once for the per-VM directory we created, and not try
to associate it with any chardev
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Fri, Aug 14, 2015 at 12:09:13PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 14, 2015 at 12:20:46PM +0200, Martin Kletzander wrote:
On Fri, Aug 14, 2015 at 11:10:05AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 14, 2015 at 11:58:54AM +0200, Martin Kletzander wrote:
On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 13, 2015 at 05:47:42PM +0200, Martin Kletzander wrote:
We are currently unable to label parent directories for some paths.
However, we will need to have per-domain directories that we would like
to have labelled, but we can't label all of them. So let's add a
boolean variable that will determine whether parent directory for such
chardev should be labelled as well as that character device itself.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/conf/domain_conf.h | 1 +
src/security/security_dac.c | 13 -
src/security/security_selinux.c | 13 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e1872bca002c..9d549a395e29 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1191,6 +1191,7 @@ struct _virDomainChrSourceDef {
} udp;
struct {
char *path;
+bool autopath;
bool listen;
} nix;
int spicevmc;
I don't think we need this - it seems we can just pass a 'bool labelParent'
parameter into virSecurityManagerSetChardevLabel() when calling it for
the monitor socket.
It's not used only for the monitor socket, but mainly for virtio
channel's target's unix socket as well and maybe more in the future.
But I agree it could be named 'labelParent' as well. Should I resend
it with that changed?
In the non-monitor cases how will we decide whether it is appropriate
to set labelParent or not ? Those paths are broadly user specified,
so we can't assume the parent is per-VM
We will label only those that we are sure that are per-VM, so only
those that are generated by the qemu driver itself. That's exactly
what the parameter is used for -- labelling parent directories only
for those paths that are auto-generated by us, but leaving all
user-specified ones alone.
IIUC, the paths generated by us will all end up in the same directory.
So if we label that directory when setting up the monitor, then it
will be correct for all the other paths too, so it doesn't seem like
we need to store this parameter in virDomainDef. In fact, I tend to
think we should perhaps add a virSecurityManagerSetDirLabel() that
we just invoke once for the per-VM directory we created, and not try
to associate it with any chardev
Monitor socket goes to $LIBDIR/libvirt/qemu/domain-$DOM/monitor.sock,
the other mentioned sockets go to
$LIBDIR/libvirt/qemu/channel/target/domain-$DOM/$NAME due to the fact
that it was pre-existing. It's also good to have that separated so
users can specify targets with name 'monitor.sock'.
I thought about the virSecurityManagerSetDirLabel(), but I didn't want
to make this more complicated than it already is.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: fix the error cover issue in qemuDomainAddCgroupForThread
Just like commit 704cf06, the error already will be set in
virCgroup* function, and virCgroupAddTask will return -1,
so We will always report error Operation not permitted
in this place.
Signed-off-by: Luyao Huang lhu...@redhat.com
---
src/qemu/qemu_driver.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index fa655b5..e0d7fa5 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4606,9 +4606,6 @@ qemuDomainAddCgroupForThread(virCgroupPtr cgroup,
/* Add pid/thread to the cgroup */
rv = virCgroupAddTask(new_cgroup, pid);
if (rv 0) {
-virReportSystemError(-rv,
- _(unable to add id %d task %d to cgroup),
- idx, pid);
virCgroupRemove(new_cgroup);
goto error;
}
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 3/3] virt-shell: Move generic commands implementation to vsh.c
I talked to Martin and Michal about this and I agree with them that
moving the command structures as well as the commands is better idea
than leaving the structures in virsh.c so I'll send a v4 inline patch.
Erik
On 13/08/15 13:39, Erik Skultety wrote:
Generic commands like 'help', 'cd', 'pwd',etc. can be reused by any
client, so the clients should profit from this implementation rather
than providing their own similar implementation (if it's not intensional
and there's a reason for this)
---
tools/virsh.c | 343
+++---
tools/vsh.c | 155 ++
tools/vsh.h | 7 ++
3 files changed, 250 insertions(+), 255 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 2d198cd..e123ea2 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -188,79 +188,6 @@ virshReconnect(vshControl *ctl)
priv-blockJobNoBytes = false;
}
-
-/*
- * connect command
- */
-static const vshCmdInfo info_connect[] = {
-{.name = help,
- .data = N_((re)connect to hypervisor)
-},
-{.name = desc,
- .data = N_(Connect to local hypervisor. This is built-in
-command after shell start up.)
-},
-{.name = NULL}
-};
-
-static const vshCmdOptDef opts_connect[] = {
-{.name = name,
- .type = VSH_OT_STRING,
- .flags = VSH_OFLAG_EMPTY_OK,
- .help = N_(hypervisor connection URI)
-},
-{.name = readonly,
- .type = VSH_OT_BOOL,
- .help = N_(read-only connection)
-},
-{.name = NULL}
-};
-
-static bool
-cmdConnect(vshControl *ctl, const vshCmd *cmd)
-{
-bool ro = vshCommandOptBool(cmd, readonly);
-const char *name = NULL;
-virshControlPtr priv = ctl-privData;
-
-if (priv-conn) {
-int ret;
-
-virConnectUnregisterCloseCallback(priv-conn, virshCatchDisconnect);
-ret = virConnectClose(priv-conn);
-if (ret 0)
-vshError(ctl, %s, _(Failed to disconnect from the
hypervisor));
-else if (ret 0)
-vshError(ctl, %s, _(One or more references were leaked after
- disconnect from the hypervisor));
-priv-conn = NULL;
-}
-
-VIR_FREE(ctl-name);
-if (vshCommandOptStringReq(ctl, cmd, name, name) 0)
-return false;
-
-ctl-name = vshStrdup(ctl, name);
-
-priv-useGetInfo = false;
-priv-useSnapshotOld = false;
-priv-blockJobNoBytes = false;
-priv-readonly = ro;
-
-priv-conn = virshConnect(ctl, ctl-name, priv-readonly);
-
-if (!priv-conn) {
-vshError(ctl, %s, _(Failed to connect to the hypervisor));
-return false;
-}
-
-if (virConnectRegisterCloseCallback(priv-conn, virshCatchDisconnect,
-NULL, NULL) 0)
-vshError(ctl, %s, _(Unable to register disconnect callback));
-
-return true;
-}
-
int virshStreamSink(virStreamPtr st ATTRIBUTE_UNUSED,
const char *bytes, size_t nbytes, void *opaque)
{
@@ -270,13 +197,9 @@ int virshStreamSink(virStreamPtr st ATTRIBUTE_UNUSED,
}
/* ---
- * Commands
+ * Command Info
* ---
*/
-
-/*
- * help command
- */
static const vshCmdInfo info_help[] = {
{.name = help,
.data = N_(print help)
@@ -288,55 +211,6 @@ static const vshCmdInfo info_help[] = {
{.name = NULL}
};
-static const vshCmdOptDef opts_help[] = {
-{.name = command,
- .type = VSH_OT_STRING,
- .help = N_(Prints global help, command specific help, or help for a
group of related commands)
-},
-{.name = NULL}
-};
-
-static bool
-cmdHelp(vshControl *ctl, const vshCmd *cmd)
- {
-const char *name = NULL;
-
-if (vshCommandOptString(ctl, cmd, command, name) = 0) {
-const vshCmdGrp *grp;
-const vshCmdDef *def;
-
-vshPrint(ctl, %s, _(Grouped commands:\n\n));
-
-for (grp = cmdGroups; grp-name; grp++) {
-vshPrint(ctl, _( %s (help keyword '%s'):\n), grp-name,
- grp-keyword);
-
-for (def = grp-commands; def-name; def++) {
-if (def-flags VSH_CMD_FLAG_ALIAS)
-continue;
-vshPrint(ctl, %-30s %s\n, def-name,
- _(vshCmddefGetInfo(def, help)));
-}
-
-vshPrint(ctl, \n);
-}
-
-return true;
-}
-
-if (vshCmddefSearch(name)) {
-return vshCmddefHelp(ctl, name);
-} else if (vshCmdGrpSearch(name)) {
-return vshCmdGrpHelp(ctl, name);
-} else {
-vshError(ctl, _(command or command group '%s' doesn't exist),
name);
-return false;
-}
-}
-
-/*
- * cd command
- */
static const vshCmdInfo info_cd[] = {
{.name = help,
.data = N_(change the current directory)
@@ -347,45 +221,6 @@ static const
[libvirt] [PATCH v4 3/4] virt-shell: Move generic commands implementation to vsh.c
Generic commands like 'help', 'cd', 'pwd',etc. can be reused by any
client, so the clients should profit from this implementation rather
than providing their own similar implementation (if it's not intensional
and there's a reason for this)
---
tools/virsh.c | 351 +-
tools/vsh.c | 245
tools/vsh.h | 71
3 files changed, 346 insertions(+), 321 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 2d198cd..391c155 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -188,20 +188,18 @@ virshReconnect(vshControl *ctl)
priv-blockJobNoBytes = false;
}
+int virshStreamSink(virStreamPtr st ATTRIBUTE_UNUSED,
+const char *bytes, size_t nbytes, void *opaque)
+{
+int *fd = opaque;
-/*
- * connect command
+return safewrite(*fd, bytes, nbytes);
+}
+
+/* ---
+ * Command Connect
+ * ---
*/
-static const vshCmdInfo info_connect[] = {
-{.name = help,
- .data = N_((re)connect to hypervisor)
-},
-{.name = desc,
- .data = N_(Connect to local hypervisor. This is built-in
-command after shell start up.)
-},
-{.name = NULL}
-};
static const vshCmdOptDef opts_connect[] = {
{.name = name,
@@ -216,6 +214,17 @@ static const vshCmdOptDef opts_connect[] = {
{.name = NULL}
};
+static const vshCmdInfo info_connect[] = {
+{.name = help,
+ .data = N_((re)connect to hypervisor)
+},
+{.name = desc,
+ .data = N_(Connect to local hypervisor. This is built-in
+command after shell start up.)
+},
+{.name = NULL}
+};
+
static bool
cmdConnect(vshControl *ctl, const vshCmd *cmd)
{
@@ -236,18 +245,18 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd)
priv-conn = NULL;
}
-VIR_FREE(ctl-name);
+VIR_FREE(ctl-connname);
if (vshCommandOptStringReq(ctl, cmd, name, name) 0)
return false;
-ctl-name = vshStrdup(ctl, name);
+ctl-connname = vshStrdup(ctl, name);
priv-useGetInfo = false;
priv-useSnapshotOld = false;
priv-blockJobNoBytes = false;
priv-readonly = ro;
-priv-conn = virshConnect(ctl, ctl-name, priv-readonly);
+priv-conn = virshConnect(ctl, ctl-connname, priv-readonly);
if (!priv-conn) {
vshError(ctl, %s, _(Failed to connect to the hypervisor));
@@ -261,281 +270,11 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd)
return true;
}
-int virshStreamSink(virStreamPtr st ATTRIBUTE_UNUSED,
-const char *bytes, size_t nbytes, void *opaque)
-{
-int *fd = opaque;
-
-return safewrite(*fd, bytes, nbytes);
-}
-
-/* ---
- * Commands
- * ---
- */
-
-/*
- * help command
- */
-static const vshCmdInfo info_help[] = {
-{.name = help,
- .data = N_(print help)
-},
-{.name = desc,
- .data = N_(Prints global help, command specific help, or help for a\n
-group of related commands)
-},
-{.name = NULL}
-};
-
-static const vshCmdOptDef opts_help[] = {
-{.name = command,
- .type = VSH_OT_STRING,
- .help = N_(Prints global help, command specific help, or help for a
group of related commands)
-},
-{.name = NULL}
-};
-
-static bool
-cmdHelp(vshControl *ctl, const vshCmd *cmd)
- {
-const char *name = NULL;
-
-if (vshCommandOptString(ctl, cmd, command, name) = 0) {
-const vshCmdGrp *grp;
-const vshCmdDef *def;
-
-vshPrint(ctl, %s, _(Grouped commands:\n\n));
-
-for (grp = cmdGroups; grp-name; grp++) {
-vshPrint(ctl, _( %s (help keyword '%s'):\n), grp-name,
- grp-keyword);
-
-for (def = grp-commands; def-name; def++) {
-if (def-flags VSH_CMD_FLAG_ALIAS)
-continue;
-vshPrint(ctl, %-30s %s\n, def-name,
- _(vshCmddefGetInfo(def, help)));
-}
-
-vshPrint(ctl, \n);
-}
-
-return true;
-}
-
-if (vshCmddefSearch(name)) {
-return vshCmddefHelp(ctl, name);
-} else if (vshCmdGrpSearch(name)) {
-return vshCmdGrpHelp(ctl, name);
-} else {
-vshError(ctl, _(command or command group '%s' doesn't exist), name);
-return false;
-}
-}
-
-/*
- * cd command
- */
-static const vshCmdInfo info_cd[] = {
-{.name = help,
- .data = N_(change the current directory)
-},
-{.name = desc,
- .data = N_(Change the current directory.)
-},
-{.name = NULL}
-};
-
-static const vshCmdOptDef opts_cd[] = {
-{.name = dir,
- .type = VSH_OT_STRING,
- .help = N_(directory to switch to (default: home or else root))
-},
-{.name = NULL}
-};
-
-static bool
-cmdCd(vshControl *ctl, const vshCmd *cmd)
-{
-const char *dir = NULL;
-char *dir_malloced = NULL;
-bool ret = true;
-char ebuf[1024];
-
-if (!ctl-imode)
Re: [libvirt] [PATCH v3 0/3] virt-shell: v3 diff series
On 14/08/15 13:52, Michal Privoznik wrote: On 13.08.2015 13:39, Erik Skultety wrote: v3: - renamed virshCommandOptTimeoutToMs - resolved conflicts caused by virsh block job handling refactor - generic commands implementation moved to vsh.c As usual, for testing purposes, everything is available on my remote branch https://github.com/eskultety/libvirt/tree/virt-shell Erik Skultety (3): virt-shell: Resolve conflicts and some forgotten substitution from v2 virt-shell: Support command history for individual clients virt-shell: Move generic commands implementation to vsh.c src/libvirt_private.syms | 1 + src/util/virstring.c | 32 src/util/virstring.h | 1 + tools/virsh-domain.c | 150 +- tools/virsh-network.c| 2 +- tools/virsh.c| 390 --- tools/virsh.h| 1 - tools/vsh.c | 242 ++--- tools/vsh.h | 13 +- 9 files changed, 441 insertions(+), 391 deletions(-) ACK with the following squashed in: diff --git a/po/POTFILES.in b/po/POTFILES.in index 1a063b6..1e52e6a 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -258,7 +258,6 @@ src/xenconfig/xen_xm.c tests/virpolkittest.c tools/libvirt-guests.sh.in tools/virsh.c -tools/virsh.h tools/virsh-console.c tools/virsh-domain-monitor.c tools/virsh-domain.c diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 9707463..eca9014 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -9813,7 +9813,7 @@ cmdDomrename(vshControl *ctl, const vshCmd *cmd) const char *new_name = NULL; bool ret = false; -if (!(dom = vshCommandOptDomain(ctl, cmd, NULL))) +if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) return ret; if (vshCommandOptStringReq(ctl, cmd, new-name, new_name) 0) Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list Thank you for review, now pushed. Erik -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4 3/4] virt-shell: Move generic commands implementation to vsh.c
On 14.08.2015 15:24, Erik Skultety wrote: Generic commands like 'help', 'cd', 'pwd',etc. can be reused by any client, so the clients should profit from this implementation rather than providing their own similar implementation (if it's not intensional and there's a reason for this) --- tools/virsh.c | 351 +- tools/vsh.c | 245 tools/vsh.h | 71 3 files changed, 346 insertions(+), 321 deletions(-) ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemuDomainRename: Report error if adding domain to domainObj list fails
So, domain renaming works like this: new domain name is added
into the list of domain objects. Then, domain definition is
updated. After that, old domain name is removed from the domain
object list. Now, if the very firs step fails for some reason, no
error is reported:
virsh # domrename dummy dummy
error: An error occurred, but the cause is unknown
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/qemu/qemu_driver.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 3683591..8e365bd 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -19950,8 +19950,11 @@ static int qemuDomainRename(virDomainPtr dom,
goto endjob;
}
-if (virDomainObjListRenameAddNew(driver-domains, vm, new_name) 0)
+if (virDomainObjListRenameAddNew(driver-domains, vm, new_name) 0) {
+virReportError(VIR_ERR_OPERATION_FAILED, %s,
+ _(could not add new name into internal list of
domains));
goto endjob;
+}
if ((logfile = qemuDomainCreateLog(driver, vm, true)) 0)
goto rollback;
--
2.4.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] nodedev: Fix gfeature size to be according to running kernel
On Thu, Aug 13, 2015 at 10:41:19AM -0400, John Ferlan wrote: On 08/13/2015 06:23 AM, Moshe Levi wrote: This patch add virNetDevGetGFeaturesSize to get the supported gfeature size from the kernel --- src/util/virnetdev.c | 79 - 1 files changed, 71 insertions(+), 8 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 2f3690e..582efda 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -90,7 +90,8 @@ VIR_LOG_INIT(util.netdev); #define RESOURCE_FILE_LEN 4096 #if HAVE_DECL_ETHTOOL_GFEATURES # define TX_UDP_TNL 25 -# define GFEATURES_SIZE 2 +# define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) Maybe we should follow the convention laine noted in one of his earlier patches and use GDIV_ROUND_UP and GFEATURE_BITS.. Although perhaps DIV_ROUND_UP seems superfluous if it's only used once. We already have VIR_DIV_UP defined in internal.h Jan signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/5] domainRename API implementation
On 12.08.2015 15:16, Michal Privoznik wrote: On 10.08.2015 21:59, Tomas Meszaros wrote: This is an effort to implement domain rename API. Presented patch series consists of the following: virDomainRename API implementation for qemu, implementation of the virsh command domrename and the additional support code. The idea behind this endeavor is to provide convenient and safe way to rename a domain. Instead of the: virsh dumpxml domain domain.xml (change domain name in domain.xml) virsh undefine domain virsh define domain.xml user can simply type: virsh domrename foo bar or call virDomainRename() API and domain foo will be renamed to bar. We currently support only renaming inactive domains without snapshots. Renaming procedure takes care of domain log, config, guest agent path and should be able to recover in case of failure. I've been working on this functionality in collaboration with Michal Privoznik who is my mentor during the GSoC 2015. If you have any questions, ideas or criticism feel free to join the discussion. v2: - removed guest agent path rename code - removed rename permission - added code for emitting undefined+renamed event for the old domain v3: - removed domain rename permission - fixed virDomainRename doc comment - added @flags parameter to the virDomainRename API Tomas Meszaros (5): Introduce virDomainRename API virsh: Implement domrename command domain_conf: Introducde virDomainObjListRenameAddNew() virDomainObjListRenameRemove() Introduce new VIR_DOMAIN_EVENT_DEFINED_RENAMED event qemu: Implement virDomainRename examples/object-events/event-test.c | 4 + include/libvirt/libvirt-domain.h| 6 ++ src/conf/domain_conf.c | 35 + src/conf/domain_conf.h | 5 ++ src/driver-hypervisor.h | 6 ++ src/libvirt-domain.c| 34 + src/libvirt_private.syms| 2 + src/libvirt_public.syms | 5 ++ src/qemu/qemu_driver.c | 145 src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x| 18 - src/remote_protocol-structs | 8 ++ tools/virsh-domain.c| 63 +++- tools/virsh.pod | 7 ++ 14 files changed, 336 insertions(+), 3 deletions(-) ACK series. Although, since this is somewhat controversial topic, I'll let others to chime in and express their feelings before pushing. Since nobody objected, I've pushed these. Good job! Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/3] virt-shell: v3 diff series
On 13.08.2015 13:39, Erik Skultety wrote: v3: - renamed virshCommandOptTimeoutToMs - resolved conflicts caused by virsh block job handling refactor - generic commands implementation moved to vsh.c As usual, for testing purposes, everything is available on my remote branch https://github.com/eskultety/libvirt/tree/virt-shell Erik Skultety (3): virt-shell: Resolve conflicts and some forgotten substitution from v2 virt-shell: Support command history for individual clients virt-shell: Move generic commands implementation to vsh.c src/libvirt_private.syms | 1 + src/util/virstring.c | 32 src/util/virstring.h | 1 + tools/virsh-domain.c | 150 +- tools/virsh-network.c| 2 +- tools/virsh.c| 390 --- tools/virsh.h| 1 - tools/vsh.c | 242 ++--- tools/vsh.h | 13 +- 9 files changed, 441 insertions(+), 391 deletions(-) ACK with the following squashed in: diff --git a/po/POTFILES.in b/po/POTFILES.in index 1a063b6..1e52e6a 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -258,7 +258,6 @@ src/xenconfig/xen_xm.c tests/virpolkittest.c tools/libvirt-guests.sh.in tools/virsh.c -tools/virsh.h tools/virsh-console.c tools/virsh-domain-monitor.c tools/virsh-domain.c diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 9707463..eca9014 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -9813,7 +9813,7 @@ cmdDomrename(vshControl *ctl, const vshCmd *cmd) const char *new_name = NULL; bool ret = false; -if (!(dom = vshCommandOptDomain(ctl, cmd, NULL))) +if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) return ret; if (vshCommandOptStringReq(ctl, cmd, new-name, new_name) 0) Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3] lxc: Inherit namespace feature
From: Imran Khan ik.n...@gmail.com This patch adds feature for lxc containers to inherit namespaces. This is very similar to what lxc-tools or docker provides. Look for man lxc-start and you will find that you can pass command args as [ --share-[net|ipc|uts] name|pid ]. Or check out docker networking option in which you can give --net=container:NAME_or_ID as an option for sharing +namespace. From this patch you can add extra libvirt option to share namespace in following way. lxc:namespace lxc:sharenet type='netns' value='red'/ lxc:shareipc type='pid' value='12345'/ lxc:shareuts type='name' value='container1'/ /lxc:namespace The netns option is specific to sharenet. It can be used to inherit from existing network namespace. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- docs/drvlxc.html.in | 21 ++ docs/schemas/domaincommon.rng | 42 po/POTFILES.in| 1 + src/Makefile.am | 6 +- src/lxc/lxc_conf.c| 2 +- src/lxc/lxc_container.c | 71 ++-- src/lxc/lxc_container.h | 2 + src/lxc/lxc_controller.c | 45 - src/lxc/lxc_domain.c | 149 ++ src/lxc/lxc_domain.h | 26 src/lxc/lxc_process.c | 149 ++ tests/lxcxml2xmltest.c| 1 + 12 files changed, 506 insertions(+), 9 deletions(-) diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index a094bd9..d6c57c4 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -590,6 +590,27 @@ Note that allowing capabilities that are normally dropped by default can serious affect the security of the container and the host. /p +h2a name=shareInherit namespaces/a/h2 + +p +Libvirt allows you to inherit the namespace from container/process just like lxc tools +or docker provides to share the network namespace. The following can be used to share +required namespaces. If we want to share only one then the other namespaces can be ignored. +The netns option is specific to sharenet. It can be used in cases we want to use existing network namespace +rather than creating new network namespace for the container. In this case privnet option will be +ignored. +/p +pre +lt;domain type='lxc' xmlns:lxc='http://libvirt.org/schemas/domain/lxc/1.0'gt; +... +lt;lxc:namespacegt; + lt;lxc:sharenet type='netns' value='red'/gt; + lt;lxc:shareuts type='name' value='container1'/gt; + lt;lxc:shareipc type='pid' value='12345'/gt; +lt;/lxc:namespacegt; +lt;/domaingt; +/pre + h2a name=usageContainer usage / management/a/h2 p diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 043c975..fa026cd 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -68,6 +68,9 @@ ref name='qemucmdline'/ /optional optional + ref name='lxcsharens'/ +/optional +optional ref name='keywrap'/ /optional /interleave @@ -5057,6 +5060,45 @@ /element /define + !-- + Optional hypervisor extensions in their own namespace: + LXC +-- + define name=lxcsharens +element name=namespace ns=http://libvirt.org/schemas/domain/lxc/1.0; + zeroOrMore +element name=sharenet + attribute name=type +choice + valuenetns/value + valuename/value + valuepid/value +/choice + /attribute + attribute name='value'/ +/element +element name=shareipc + attribute name=type +choice + valuename/value + valuepid/value +/choice + /attribute + attribute name='value'/ +/element +element name=shareuts + attribute name=type +choice + valuename/value + valuepid/value +/choice + /attribute + attribute name='value'/ +/element + /zeroOrMore +/element + /define + define name=metadata element name=metadata zeroOrMore diff --git a/po/POTFILES.in b/po/POTFILES.in index c58a7c1..dcabcc8 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -85,6 +85,7 @@ src/lxc/lxc_native.c src/lxc/lxc_container.c src/lxc/lxc_conf.c src/lxc/lxc_controller.c +src/lxc/lxc_domain.c src/lxc/lxc_driver.c src/lxc/lxc_process.c src/libxl/libxl_domain.c diff --git a/src/Makefile.am b/src/Makefile.am index c4d49a5..fde11ff 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1320,7 +1320,11 @@ libvirt_driver_lxc_impl_la_CFLAGS = \ -I$(srcdir)/access \ -I$(srcdir)/conf \ $(AM_CFLAGS) -libvirt_driver_lxc_impl_la_LIBADD = $(CAPNG_LIBS) $(LIBNL_LIBS) $(FUSE_LIBS) +libvirt_driver_lxc_impl_la_LIBADD = \ + $(CAPNG_LIBS) \ + $(LIBNL_LIBS) \ +
Re: [libvirt] [PATCH] Inherit namespace feature 2
On Sun, Aug 09, 2015 at 12:09:32AM +0530, ik.nitk wrote:
diff --git a/src/Makefile.am b/src/Makefile.am
index c4d49a5..b2ceda3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1320,7 +1320,7 @@ libvirt_driver_lxc_impl_la_CFLAGS = \
-I$(srcdir)/access \
-I$(srcdir)/conf \
$(AM_CFLAGS)
-libvirt_driver_lxc_impl_la_LIBADD = $(CAPNG_LIBS) $(LIBNL_LIBS) $(FUSE_LIBS)
+libvirt_driver_lxc_impl_la_LIBADD = $(CAPNG_LIBS) $(LIBNL_LIBS)
$(LIBXML_LIBS) libvirt-lxc.la $(FUSE_LIBS)
I understand why you needed libvirt-lxc.la in your v1 of
this patch, but with the code moved into lxc_process.c
this is no longer needed. Only LIBXML_LIBS needs adding.
diff --git a/src/lxc/lxc_conf.h b/src/lxc/lxc_conf.h
index 8340b1f..72b1d44 100644
--- a/src/lxc/lxc_conf.h
+++ b/src/lxc/lxc_conf.h
@@ -67,6 +67,21 @@ struct _virLXCDriverConfig {
bool securityRequireConfined;
};
+
+typedef enum {
+VIR_DOMAIN_NAMESPACE_SHARENET = 0,
+VIR_DOMAIN_NAMESPACE_SHAREIPC,
+VIR_DOMAIN_NAMESPACE_SHAREUTS,
+VIR_DOMAIN_NAMESPACE_LAST,
+} virDomainNamespace;
We shold really have LXC in the name, eg virLXCDomainNamespace
and VIR_LXC_DOMAIN_NAMESPACE_* constants.
+
+typedef struct _lxcDomainDef lxcDomainDef;
+typedef lxcDomainDef *lxcDomainDefPtr;
+struct _lxcDomainDef {
+char *ns_type[VIR_DOMAIN_NAMESPACE_LAST];
There are only 3 value types, so we should just have an enum
for them too, instead of comparing strings everywhere
+char *ns_val[VIR_DOMAIN_NAMESPACE_LAST];
+};
+
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 11e9514..103e9bc 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
/**
* lxcContainerStart:
@@ -2342,13 +2432,17 @@ int lxcContainerStart(virDomainDefPtr def,
int *passFDs,
int control,
int handshakefd,
+ int nsInheritFDs[VIR_DOMAIN_NAMESPACE_LAST],
size_t nttyPaths,
char **ttyPaths)
{
pid_t pid;
-int cflags;
+int cflags, i;
int stacksize = getpagesize() * 4;
char *stack, *stacktop;
+int savedNsFDs[VIR_DOMAIN_NAMESPACE_LAST];
+int preserve_mask = 0;
+lxcDomainDefPtr lxcDef;
lxc_child_argv_t args = {
.config = def,
.securityDriver = securityDriver,
@@ -2368,7 +2462,12 @@ int lxcContainerStart(virDomainDefPtr def,
stacktop = stack + stacksize;
-cflags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|SIGCHLD;
+lxcDef = def-namespaceData;
+for (i = 0; i VIR_DOMAIN_NAMESPACE_LAST; i++)
+ if (lxcDef lxcDef-ns_type[i])
+ preserve_mask |= nsInfoLocal[i].clone_flag;
+
+cflags = CLONE_NEWPID|CLONE_NEWNS|SIGCHLD;
if (userns_required(def)) {
if (userns_supported()) {
@@ -2381,10 +2480,37 @@ int lxcContainerStart(virDomainDefPtr def,
return -1;
}
}
+if (!lxcDef || !lxcDef-ns_type[VIR_DOMAIN_NAMESPACE_SHARENET]) {
We don't actually need lxcDef here at all - we should just look
at the nsInheritFDs list, eg
if (nsInheritFDs[VIR_DOMAIN_NAMESPACE_SHARENET] != -1) {
...
+if (lxcNeedNetworkNamespace(def)) {
+VIR_DEBUG(Enable network namespaces);
+cflags |= CLONE_NEWNET;
+}
+} else {
+VIR_DEBUG(Inheriting a net namespace);
We should report an error in this branch if lxcNeedNetworkNamespace
returns true, as that indicates a contradictory XML config.
+}
-if (lxcNeedNetworkNamespace(def)) {
-VIR_DEBUG(Enable network namespaces);
-cflags |= CLONE_NEWNET;
+if (!lxcDef || !lxcDef-ns_type[VIR_DOMAIN_NAMESPACE_SHAREIPC]) {
+cflags |= CLONE_NEWIPC;
+} else {
+VIR_DEBUG(Inheriting an IPC namespace);
+}
+
+if (!lxcDef || !lxcDef-ns_type[VIR_DOMAIN_NAMESPACE_SHAREUTS]) {
+cflags |= CLONE_NEWUTS;
+} else {
+VIR_DEBUG(Inheriting a UTS namespace);
+}
+
+if (lxcDef lxcPreserve_ns(savedNsFDs, preserve_mask) 0) {
+virReportError(VIR_ERR_SYSTEM_ERROR, %s,
+ _(failed to preserve the namespace));
+return -1;
+}
+
+if (lxcDef lxcAttach_ns(nsInheritFDs) 0) {
+virReportError(VIR_ERR_SYSTEM_ERROR, %s,
+ _(failed to attach the namespace));
+return -1;
}
VIR_DEBUG(Cloning container init process);
@@ -2397,7 +2523,14 @@ int lxcContainerStart(virDomainDefPtr def,
_(Failed to run clone container));
return -1;
}
+if (lxcDef lxcAttach_ns(savedNsFDs)) {
+virReportError(VIR_ERR_SYSTEM_ERROR, %s,
+ _(failed to restore saved namespaces));
+}
You are in libvirt_lxc controller context here, so I see
why you have to preserve re-attach
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Fri, Aug 14, 2015 at 01:43:16PM +0200, Martin Kletzander wrote: On Fri, Aug 14, 2015 at 12:09:13PM +0100, Daniel P. Berrange wrote: On Fri, Aug 14, 2015 at 12:20:46PM +0200, Martin Kletzander wrote: On Fri, Aug 14, 2015 at 11:10:05AM +0100, Daniel P. Berrange wrote: On Fri, Aug 14, 2015 at 11:58:54AM +0200, Martin Kletzander wrote: On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote: I don't think we need this - it seems we can just pass a 'bool labelParent' parameter into virSecurityManagerSetChardevLabel() when calling it for the monitor socket. It's not used only for the monitor socket, but mainly for virtio channel's target's unix socket as well and maybe more in the future. But I agree it could be named 'labelParent' as well. Should I resend it with that changed? In the non-monitor cases how will we decide whether it is appropriate to set labelParent or not ? Those paths are broadly user specified, so we can't assume the parent is per-VM We will label only those that we are sure that are per-VM, so only those that are generated by the qemu driver itself. That's exactly what the parameter is used for -- labelling parent directories only for those paths that are auto-generated by us, but leaving all user-specified ones alone. IIUC, the paths generated by us will all end up in the same directory. So if we label that directory when setting up the monitor, then it will be correct for all the other paths too, so it doesn't seem like we need to store this parameter in virDomainDef. In fact, I tend to think we should perhaps add a virSecurityManagerSetDirLabel() that we just invoke once for the per-VM directory we created, and not try to associate it with any chardev Monitor socket goes to $LIBDIR/libvirt/qemu/domain-$DOM/monitor.sock, the other mentioned sockets go to $LIBDIR/libvirt/qemu/channel/target/domain-$DOM/$NAME due to the fact that it was pre-existing. It's also good to have that separated so users can specify targets with name 'monitor.sock'. Ok, so we have 2 distinct well known directories that we can expect to need to label. I thought about the virSecurityManagerSetDirLabel(), but I didn't want to make this more complicated than it already is. I rather think it will be clearer/simpler if we use a SetDirLabel() approach, as we know for sure we're labelling a directory that we have explicitly designated as per-VM, and not have to try to determine that indirectly by looking at the chardev path each time. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: add a check for nodeset in qemuDomainSetNumaParamsLive
We will try to set the node to cpuset.mems without check if it is available, since we already have helper to check this. Call virNumaNodesetIsAvailable to check if node is available, then try to change it in the cgroup. Signed-off-by: Luyao Huang lhu...@redhat.com --- src/qemu/qemu_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index fa655b5..45dfca0 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9977,6 +9977,9 @@ qemuDomainSetNumaParamsLive(virDomainObjPtr vm, goto cleanup; } +if (!virNumaNodesetIsAvailable(nodeset)) +goto cleanup; + /* Ensure the cpuset string is formatted before passing to cgroup */ if (!(nodeset_str = virBitmapFormat(nodeset))) goto cleanup; -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Fri, Aug 14, 2015 at 11:10:05AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 14, 2015 at 11:58:54AM +0200, Martin Kletzander wrote:
On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 13, 2015 at 05:47:42PM +0200, Martin Kletzander wrote:
We are currently unable to label parent directories for some paths.
However, we will need to have per-domain directories that we would like
to have labelled, but we can't label all of them. So let's add a
boolean variable that will determine whether parent directory for such
chardev should be labelled as well as that character device itself.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/conf/domain_conf.h | 1 +
src/security/security_dac.c | 13 -
src/security/security_selinux.c | 13 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e1872bca002c..9d549a395e29 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1191,6 +1191,7 @@ struct _virDomainChrSourceDef {
} udp;
struct {
char *path;
+bool autopath;
bool listen;
} nix;
int spicevmc;
I don't think we need this - it seems we can just pass a 'bool labelParent'
parameter into virSecurityManagerSetChardevLabel() when calling it for
the monitor socket.
It's not used only for the monitor socket, but mainly for virtio
channel's target's unix socket as well and maybe more in the future.
But I agree it could be named 'labelParent' as well. Should I resend
it with that changed?
In the non-monitor cases how will we decide whether it is appropriate
to set labelParent or not ? Those paths are broadly user specified,
so we can't assume the parent is per-VM
We will label only those that we are sure that are per-VM, so only
those that are generated by the qemu driver itself. That's exactly
what the parameter is used for -- labelling parent directories only
for those paths that are auto-generated by us, but leaving all
user-specified ones alone.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 13, 2015 at 05:47:42PM +0200, Martin Kletzander wrote:
We are currently unable to label parent directories for some paths.
However, we will need to have per-domain directories that we would like
to have labelled, but we can't label all of them. So let's add a
boolean variable that will determine whether parent directory for such
chardev should be labelled as well as that character device itself.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/conf/domain_conf.h | 1 +
src/security/security_dac.c | 13 -
src/security/security_selinux.c | 13 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e1872bca002c..9d549a395e29 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1191,6 +1191,7 @@ struct _virDomainChrSourceDef {
} udp;
struct {
char *path;
+bool autopath;
bool listen;
} nix;
int spicevmc;
I don't think we need this - it seems we can just pass a 'bool labelParent'
parameter into virSecurityManagerSetChardevLabel() when calling it for
the monitor socket.
It's not used only for the monitor socket, but mainly for virtio
channel's target's unix socket as well and maybe more in the future.
But I agree it could be named 'labelParent' as well. Should I resend
it with that changed?
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/7] security: Label parent directories of character devices
On Fri, Aug 14, 2015 at 11:58:54AM +0200, Martin Kletzander wrote:
On Thu, Aug 13, 2015 at 04:59:47PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 13, 2015 at 05:47:42PM +0200, Martin Kletzander wrote:
We are currently unable to label parent directories for some paths.
However, we will need to have per-domain directories that we would like
to have labelled, but we can't label all of them. So let's add a
boolean variable that will determine whether parent directory for such
chardev should be labelled as well as that character device itself.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/conf/domain_conf.h | 1 +
src/security/security_dac.c | 13 -
src/security/security_selinux.c | 13 -
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e1872bca002c..9d549a395e29 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1191,6 +1191,7 @@ struct _virDomainChrSourceDef {
} udp;
struct {
char *path;
+bool autopath;
bool listen;
} nix;
int spicevmc;
I don't think we need this - it seems we can just pass a 'bool labelParent'
parameter into virSecurityManagerSetChardevLabel() when calling it for
the monitor socket.
It's not used only for the monitor socket, but mainly for virtio
channel's target's unix socket as well and maybe more in the future.
But I agree it could be named 'labelParent' as well. Should I resend
it with that changed?
In the non-monitor cases how will we decide whether it is appropriate
to set labelParent or not ? Those paths are broadly user specified,
so we can't assume the parent is per-VM
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
