It may happen that in the list of paths/disk sources to relabel
there is a disk source. If that is the case, the path is NULL. In
that case, we shouldn't try to lock the path. It's likely a
network disk anyway and therefore there is nothing to lock.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
src/security/security_dac.c | 3 ++-
src/security/security_selinux.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index 876cca0f2f..04168feb3d 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -216,7 +216,8 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
for (i = 0; i < list->nItems; i++) {
const char *p = list->items[i]->path;
- if (virFileIsDir(p))
+ if (!p ||
+ virFileIsDir(p))
continue;
VIR_APPEND_ELEMENT_COPY_INPLACE(paths, npaths, p);
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index 3c847d8dcb..3adbeada14 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -227,7 +227,8 @@ virSecuritySELinuxTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
for (i = 0; i < list->nItems; i++) {
const char *p = list->items[i]->path;
- if (virFileIsDir(p))
+ if (!p ||
+ virFileIsDir(p))
continue;
VIR_APPEND_ELEMENT_COPY_INPLACE(paths, npaths, p);
--
2.16.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Sep 25, 2018 at 09:34:50AM +0200, Michal Privoznik wrote:
> It may happen that in the list of paths/disk sources to relabel
> there is a disk source. If that is the case, the path is NULL. In
Is there a way to prevent to such a source would not make it into the list in
the first place?
> that case, we shouldn't try to lock the path. It's likely a
> network disk anyway and therefore there is nothing to lock.
>
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
> src/security/security_dac.c | 3 ++-
> src/security/security_selinux.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> index 876cca0f2f..04168feb3d 100644
> --- a/src/security/security_dac.c
> +++ b/src/security/security_dac.c
> @@ -216,7 +216,8 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
> for (i = 0; i < list->nItems; i++) {
> const char *p = list->items[i]->path;
>
> - if (virFileIsDir(p))
> + if (!p ||
> + virFileIsDir(p))
^this easily fits on the same line...
Erik
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 09/25/2018 12:47 PM, Erik Skultety wrote:
> On Tue, Sep 25, 2018 at 09:34:50AM +0200, Michal Privoznik wrote:
>> It may happen that in the list of paths/disk sources to relabel
>> there is a disk source. If that is the case, the path is NULL. In
>
> Is there a way to prevent to such a source would not make it into the list in
> the first place?
Not at all. Disk source may consists of variety of strings. A path is
just one of the options. The other is host FQN for iscsi, rbd, ceph and
all sorts of other beasts. And yet, we might want to relabel them.
>
>> that case, we shouldn't try to lock the path. It's likely a
>> network disk anyway and therefore there is nothing to lock.
>>
>> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>> ---
>> src/security/security_dac.c | 3 ++-
>> src/security/security_selinux.c | 3 ++-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
>> index 876cca0f2f..04168feb3d 100644
>> --- a/src/security/security_dac.c
>> +++ b/src/security/security_dac.c
>> @@ -216,7 +216,8 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
>> for (i = 0; i < list->nItems; i++) {
>> const char *p = list->items[i]->path;
>>
>> - if (virFileIsDir(p))
>> + if (!p ||
>> + virFileIsDir(p))
>
> ^this easily fits on the same line...
Yep, I just wanted to separate these conditions as they both serve
different purposes. But I can move it onto a single line if desired.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Sep 25, 2018 at 01:01:59PM +0200, Michal Privoznik wrote: > On 09/25/2018 12:47 PM, Erik Skultety wrote: > > On Tue, Sep 25, 2018 at 09:34:50AM +0200, Michal Privoznik wrote: > >> It may happen that in the list of paths/disk sources to relabel > >> there is a disk source. If that is the case, the path is NULL. In > > > > Is there a way to prevent to such a source would not make it into the list in > > the first place? > > Not at all. Disk source may consists of variety of strings. A path is > just one of the options. The other is host FQN for iscsi, rbd, ceph and > all sorts of other beasts. And yet, we might want to relabel them. Fair enough. Reviewed-by: Erik Skultety <eskultet@redhat.com> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 9/25/18 3:34 AM, Michal Privoznik wrote:
> It may happen that in the list of paths/disk sources to relabel
> there is a disk source. If that is the case, the path is NULL. In
> that case, we shouldn't try to lock the path. It's likely a
> network disk anyway and therefore there is nothing to lock.
I think this needs a tweak to reference commit 6d855abc1 which only
filtered if the provided @p was a directory. This adds another filter
when @p is NULL such as would be the case with networked storage.
NB: The storage source is only passed for DAC and not selinux. The DAC
code makes a some valiant attempts at src->path if not Local too. The
selinux code has lots of branches and callers which seem to validly pass
a path, but I could have missed a path or some nuance.
The "key" is chasing virSecurityDACChownListAppend and
virSecuritySELinuxContextListAppend where the list->[n]items is
populated via VIR_APPEND_ELEMENT. Expect to spend some time on the chase!
You already have an R-by and I don't have anything else to provide on
this particular one other than yeah, better safe than sorry and passing
NULL. Although I have to imagine the stat(NULL, &s) in virFileIsDir
wouldn't have been pleased.
John
>
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
> src/security/security_dac.c | 3 ++-
> src/security/security_selinux.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> index 876cca0f2f..04168feb3d 100644
> --- a/src/security/security_dac.c
> +++ b/src/security/security_dac.c
> @@ -216,7 +216,8 @@ virSecurityDACTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
> for (i = 0; i < list->nItems; i++) {
> const char *p = list->items[i]->path;
>
> - if (virFileIsDir(p))
> + if (!p ||
> + virFileIsDir(p))
> continue;
>
> VIR_APPEND_ELEMENT_COPY_INPLACE(paths, npaths, p);
> diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
> index 3c847d8dcb..3adbeada14 100644
> --- a/src/security/security_selinux.c
> +++ b/src/security/security_selinux.c
> @@ -227,7 +227,8 @@ virSecuritySELinuxTransactionRun(pid_t pid ATTRIBUTE_UNUSED,
> for (i = 0; i < list->nItems; i++) {
> const char *p = list->items[i]->path;
>
> - if (virFileIsDir(p))
> + if (!p ||
> + virFileIsDir(p))
> continue;
>
> VIR_APPEND_ELEMENT_COPY_INPLACE(paths, npaths, p);
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.