Re: [Libguestfs] [common PATCH 3/3] mlcustomize: do not relabel if not enforcing (RHBZ#1828952)

On Thu, Sep 24, 2020 at 02:16:24PM +0200, Pino Toscano wrote: > On Thursday, 24 September 2020 13:53:57 CEST Richard W.M. Jones wrote: > > > Considering that /tmp is a general location for temporary files, it's > > > common that files may end with a tmp_t-alike label when moved back to > > > the destination place (e.g. after a rename()). That is not the only > > > situation like this that I saw in the past. > > > > > > In permissive mode, all these situation are logged in the audit log, > > > yes, but they cause no blocks nor errors. > > > > > > > It's also fine for an administrator to > > > > switch a system to permissive and then back to enforcing without > > > > relabelling or rebooting. > > > > > > A mislabelled /etc/passwd is still read and used fine in permissive > > > mode. Switch back from permissive to enforcing without a relabelling > > > is generally not a good idea, especially after the system ran for a > > > lot of time after the switch to permissive. > > > > It's seems true from what you wrote above that someone could copy > > /tmp/passwd -> /etc/passwd and it would have a wrong label. But > > virt-v2v could fix that label, which even in permissive mode sounds > > like a win. > > The question is: why? If the system had wrong labels even for system > files, and the administrator did not bother/want to fix them (because > of permissive), why should virt-v2v? Even if virt-v2v relabels a > permissive guest, the labels will get out of sync once the guest runs > again and does its own stuff, so there is no gain here. I don't think this part is true (except in rather contrived situations).

It seems as if when setting the mode to Permissive when the guest is running normally, it *is* attempting to maintain the correct labels.

So virt-v2v should do the same thing.