similar to: SELinux relabel API

Rewrite the relabel API to read the policy configured in the guest, invoking setfiles (added as part of the appliance, as part of policycoreutils) to relabel the specified root. In case of failure at any point of the process, a touch of .autorelabel in the root is tried as last-attempt measure to do the relabel. Considering that running SELinux tools in the appliance might be affected by the

Continuation/rework of: https://www.redhat.com/archives/libguestfs/2020-May/msg00020.html This is my approach, as I explained here: https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c4 https://www.redhat.com/archives/libguestfs/2020-May/msg00035.html IOW: do not attempt to relabel if the guest is not enforcing, as it is either useless or may fail; few words more are in the comments of patch #3.

On Tuesday 27 May 2014 09:08:27 Richard W.M. Jones wrote: > On Mon, May 26, 2014 at 11:21:59AM +0200, Pino Toscano wrote: > > Rewrite the relabel API to read the policy configured in the guest, > > invoking setfiles (added as part of the appliance, as part of > > policycoreutils) to relabel the specified root. In case of failure > > at > > any point of the process,

v1 -> v2: - Add simple test of the setfiles API. - Use SELinux_relabel module in virt-v2v (instead of touch /.autorelabel). - Small fixes. Rich.

This shouldn't change the effect of this code. --- mlcustomize/SELinux_relabel.ml | 121 ++++++++++++++++++--------------- 1 file changed, 65 insertions(+), 56 deletions(-) diff --git a/mlcustomize/SELinux_relabel.ml b/mlcustomize/SELinux_relabel.ml index 44995df..5df1f08 100644 --- a/mlcustomize/SELinux_relabel.ml +++ b/mlcustomize/SELinux_relabel.ml @@ -28,65 +28,74 @@ module G = Guestfs

We can use the setfiles(8) command to relabel the guest filesystem, even though we don't have a policy loaded nor SELinux enabled in the appliance kernel. This also deprecates or removes the old and broken SELinux support. This patch isn't quite complete - I would like to add some tests to the new API. I'm posting here to garner early feedback. Rich.

[This email is either empty or too large to be displayed at this time]

On Wed, Sep 23, 2020 at 05:57:50PM +0200, Pino Toscano wrote: > Do not attempt to relabel a guest in case its SELinux enforcing mode is > not "enforcing", as it is either pointless, or it may fail because of an > invalid policy configured. > --- > mlcustomize/SELinux_relabel.ml | 26 +++++++++++++++++++++++++- > 1 file changed, 25 insertions(+), 1 deletion(-) >

Instead of just documenting this bug, fix it in the file_contexts file. Replaces commit ad3c8fe7f49c4991e1aa536856a1a408f55d5409. --- customize/SELinux_relabel.ml | 19 +++++++++++++++++++ v2v/virt-v2v.pod | 11 ----------- 2 files changed, 19 insertions(+), 11 deletions(-) diff --git a/customize/SELinux_relabel.ml b/customize/SELinux_relabel.ml index fa9603c..69a4779 100644 ---

On Sun, Dec 24, 2017 at 3:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, Dec 24, 2017 at 02:15:44PM +0200, Yaniv Kaul wrote: > > I'm copying a file into a VM using virt-copy-in - which is great, but the > > file is wrongly labeled. > > How can I fix that? > > Hi Yaniv, > > The easiest thing is to run this after doing the virt-copy-in:

v1 -> v2: Match more specifically. Rich.

Hi, On Wed, November 16, 2016 11:10 am, Richard W.M. Jones wrote: > >> It eventually did complete, after several hours. But I don't understand >> why this particular VM took so long when others (with similar disk >> sizes/usages/configurations) completed in only 1-2 minutes. Each VM is >> effectively exactly the same (it's a build slave), so it's just the

> -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Tuesday, March 6, 2018 11:49 AM > To: Зиновик Игорь Анатольевич <ZinovikIA@nspk.ru> > Cc: libguestfs@redhat.com > Subject: Re: [Libguestfs] virt-v2v 1.38 fails to convert .vmx VM: setfiles ... > Multiple same specifications for /.*. > > On Tue, Mar 06, 2018 at 08:40:51AM

Hello, Richard. > -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Monday, March 5, 2018 8:42 PM > To: Зиновик Игорь Анатольевич <ZinovikIA@nspk.ru> > Cc: libguestfs@redhat.com > Subject: Re: [Libguestfs] virt-v2v 1.38 fails to convert .vmx VM: setfiles ... > Multiple same specifications for /.*. > > On Mon, Mar 05, 2018 at

Do SELinux relabelling properly.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1212807

Hi Rich, On Wed, November 16, 2016 1:34 pm, Richard W.M. Jones wrote: > On Wed, Nov 16, 2016 at 11:31:40AM -0500, Derek Atkins wrote: >> > Running `virt-v2v -v -x ...' and observing the output will give you a >> > good idea of what precisely it was doing for those hours. >> >> Well, as I said in my original email, it was hanging at running >> setfiles:

Hello everyone, If create a folder called "whatever" under /var, the context is: root:object_r:var_t /var/whatever/ That's expected as it is under /var. If I then change its type: chcont -t httpd_sys_content_t /var/whatever The context looks like: root:object_r:httpd_sys_content_t /var/whatever/ My question is...Shouldn't a relabeling of the filesystem change the type

[This email is either empty or too large to be displayed at this time]

If the guest uses SELinux, then make sure to run a relabel (or at least schedule one) after the image build: this way the template is relabelled, or at least it will do that at the next boot, without the need for the user to ask for a relabel. This just covers the case of building a new image with no additional operations on it though. --- builder/website/centos.sh | 2 ++