Re: Issue with fixfiles excludes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 25, 2020 at 11:57 AM Chris Adams <linux@xxxxxxxxxxx> wrote:
>
> After an SELinux policy update on Fedora 31 triggered a fixfiles that
> ran for hours and hours, I looked into why.  It turns out that I have
> BackupPC backing up to a different location (separate filesystem mounted
> under /srv), so fixfiles was going through millions and millions of
> files/directories.
>
> There's a hard-coded exclude list in fixfiles that includes
> /var/lib/BackupPC, which seems weird (why BackupPC and no other backup
> program?).  Also, there's support for a separate local exclude list -
> it's in the man page, but IMHO a little buried towards the end of a
> paragraph.
>
> My suggestion would be:
>
> - Make the exclude documentation separated in the man page to make it
>   stand out more.
>
> - Make the exclude file a exclude.d directory, so packages can drop in
>   exclusions (maybe /etc/selinux/fixfiles.d/*.exclude or the like).
>
> - Remove most/all of the hard-coded exclusions from the script and move
>   them to relevant packages; could maybe keep the virtual FS like /sys
>   and /proc in the script, but even put things like /mnt and /home in a
>   fixfiles.d/default.exclude so they could be overridden by local
>   policy.  Then if BackupPC should be excluded, the BackupPC package
>   would include the config (which would be a little more obvious to see
>   if you move its storage).
>
> Is there any upstream interest in this?  It would all be
> straight-forward to change - I can submit a patch if there's a
> reasonable chance it would be accepted.

This sounds reasonable.  However, these days libselinux
selinux_restorecon(3) which gets used internally by
setfiles/restorecon (which is what fixfiles executes to perform
relabeling) should be automatically excluding any filesystems that do
not support security labeling based on /proc/self/mounts and the
seclabel option.  Hence, manual exclude lists should only be necessary
for filesystem types that support security labeling by userspace
and/or for running setfiles/fixfiles when SELinux is disabled (e.g. to
label before first booting with SELinux enabled).



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux