search for: relabeling

the description of the --selinux-relabel option suggests that it perform an immediate relabel, when in fact it may (and probably will) instead simply touch /.autorelabel on the image, which schedules a relabel operation for the next time the image boots. This can be surprising because it results both in an extended initial boot time *and* results in an automatic reboot (on some distributions).

This shows which files are being relabelled. Also only use -q (suppress non-error output) when we are not verbose. --- daemon/selinux-relabel.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/daemon/selinux-relabel.c b/daemon/selinux-relabel.c index 2f48ee6..e7da42d 100644 --- a/daemon/selinux-relabel.c +++ b/daemon/selinux-relabel.c @@ -112,8 +112,11 @@

...> From: Martin Kletzander <mkletzan@redhat.com> > To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> > Cc: Eric Blake <eblake@redhat.com>; libvirt-users <libvirt-users@redhat.com> > Sent: Tuesday, August 20, 2013 6:05 PM > Subject: Re: [libvirt-users] Stop the relabeling of CD images > > On 08/20/2013 04:19 AM, Cristian Ciupitu wrote: >> ----- Original Message ----- >>> From: Eric Blake <eblake@redhat.com> >>> To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> >>> Cc: libvirt-users <libvirt-users@redhat.com> &...

----- Original Message ----- > From: Eric Blake <eblake@redhat.com> > To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> > Cc: libvirt-users <libvirt-users@redhat.com> > Sent: Monday, August 19, 2013 11:24 PM > Subject: Re: [libvirt-users] Stop the relabeling of CD images > So maybe this would do it: > > <source file=...> >   <seclabel model='selinux' relabel='no'/> >   <seclabel model='dac' relabel='no'/> > </source> I've just tried it and the SELinux label is not changed a...

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

[ I realized that we were discussing adding this feature, in various private email, IRC, and this long bugzilla thread: https://bugzilla.redhat.com/show_bug.cgi?id=1060423 That's not how we should do things. Let's discuss it on the mailing list. ] One thing that virt-customize/virt-sysprep/virt-builder have to do is relabel SELinux guests. What we do at the moment

Hi, I'm installing the operating system for my virtual machines from CD images and I would like for libvirtd to stop relabeling the corresponding files.  Since the installation media is no big secret, I have labeled the files with system_u:object_r:public_content_t:s0, but libvirtd keeps changing them to system_u:object_r:svirt_image_t:s0.  It also changes the ownership to qemu:qemu.  This means that I can not make the file...

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:

This implements the --selinux-relabel option for virt-customize, virt-builder and virt-sysprep. There is no need to autorelabel functionality now. Thanks: Stephen Smalley --- builder/Makefile.am | 1 + builder/virt-builder.pod | 20 +++++++++---------- customize/Makefile.am | 2 ++ customize/SELinux_relabel.ml | 46 +++++++++++++++++++++++++++++++++++++++++++

...x labels", and then learning via IRC that the labels were incorrect because extra packages are installed with the image mounted on the libguestfs appliance, which runs with selinux disabled. What is preventing virt-builder from automatically making a correct determination about whether or not relabeling must be done?

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 Thu, Sep 24, 2020 at 12:39:02PM +0200, Pino Toscano wrote: ... > There are various cases when, even of an enforcing system, labels are > not kept up-to-date: > > $ getenforce > Enforcing > $ touch /tmp/test > $ ls -lZ /tmp/test > -rw-rw-r--. 1 ptoscano ptoscano unconfined_u:object_r:user_tmp_t:s0 0 Sep 24 12:26 /tmp/test > $ mv /tmp/test ~/var/ > $ ls -lZ

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(-) >

On Thu, Mar 24, 2016 at 03:21:45PM -0400, Lars Kellogg-Stedman wrote: > the description of the --selinux-relabel option suggests that it > perform an immediate relabel, when in fact it may (and probably will) > instead simply touch /.autorelabel on the image, which schedules a > relabel operation for the next time the image boots. This can be > surprising because it results both in

On 08/19/2013 01:51 PM, Cristian Ciupitu wrote: > Hi, > > I'm installing the operating system for my virtual machines from CD > images and I would like for libvirtd to stop relabeling the > corresponding files. Since the installation media is no big secret, I > have labeled the files with system_u:object_r:public_content_t:s0, but > libvirtd keeps changing them to system_u:object_r:svirt_image_t:s0. It > also changes the ownership to qemu:qemu. This means that I c...

...virtd is running under prevents it from > > > re-labelling, then TAP devices label failure is just going to be one > > > out of 100's of labelling failures. > > > > > IIUC normally libvirtd would use devices created by itself, so there > > shouldn't be relabeling failures, right? > > Whether or not there are relabeling failures is determined by what > SELinux policy libvirtd is running under. > > > > > > > Either the SELinux policy needs to be changed to allow libvirtd to > > > relabel stuff in the normal manner, or yo...

...libvirt? > > If the SELinux policy that libvirtd is running under prevents it from > re-labelling, then TAP devices label failure is just going to be one > out of 100's of labelling failures. > IIUC normally libvirtd would use devices created by itself, so there shouldn't be relabeling failures, right? > > Either the SELinux policy needs to be changed to allow libvirtd to > relabel stuff in the normal manner, or you will have to turn off > SELinux support in libvirtd. in /etc/libvirt/qemu.conf via the > param security_driver = "none". If you turn off S...

Do SELinux relabelling properly.

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,

I have 4000 observations that I need to randomly relabel 1000 times and then calculate the mean of the 1000 values at each of the 4000 points. Any ideas for where to begin? Thanks Kevin -- View this message in context: http://r.789695.n4.nabble.com/Random-Relabelling-tp3463100p3463100.html Sent from the R help mailing list archive at Nabble.com.