search for: relabels

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 @@

----- Original Message ----- > 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

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

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

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 +++++++++++++++++++++++++++++++++++++++++++

On 02/06/2018 10:53 AM, Pino Toscano wrote: > On Tuesday, 6 February 2018 16:40:04 CET Daniel P. Berrangé wrote: >> When you tell virt-builder to install extra RPMs, this potentially >> looses the SELinux labelling that Anaconda had originally setup. Thus we >> must tell virt-builder to enable SELinux relabelling. >> >> Signed-off-by: Daniel P. Berrangé

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

On Tue, Jul 14, 2020 at 6:03 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Jul 14, 2020 at 04:02:17PM +0300, Ram Lavi wrote: > > On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <berrange@redhat.com> > > wrote: > > > > > On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote: > > > > Hello all, > > > > > >

On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote: > > Hello all, > > > > tl;dr, can you point me to the point in the libvirt repo where it's > trying > > to change a tap-device's SELinux label? > > > > I am trying to create a tap device with libvirt on

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.