Re: [PATCH] restorecon: Add option to count number of relabeled files

[William Roberts <bill.c.roberts@gmail.com>]

On Thu, Nov 13, 2025 at 11:36 AM Daniel Burgener
<dburgener@linux.microsoft.com> wrote:
>
> On 11/12/2025 7:43 PM, William Roberts wrote:
> > On Tue, Nov 11, 2025 at 10:34 AM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> >>
> >> <snip>
> >>>>> I'm no longer an SELinux maintainer, so don't let my nack stop anyone.
> >>>
> >>> We have a need for a similar use case in terms of ensuring that
> >>> restorecon actually performed relabeling, but I agree that I don't think
> >>> this patch as is would meet our needs.
> >>>
> >>> One thing that might make the patch more usable and address these
> >>> comments would be to instead pass the expected number of relabels as an
> >>> argument to restorecon and then return success if the relabel count ==
> >>> the expected count.  That avoids all the problems around exit code
> >>> handling while still verifying the count.
> >>>
> >>> The other problem though is that in the presence of globbing it's not
> >>> clear that getting the expected number of files relabeled means that you
> >>> actually relabeled the files you expected to.  But I guess the answer to
> >>> that is just "don't use the count feature with globbing".  Even without
> >>> globbing though, if you don't relabel all the files, you don't know
> >>> which one you skipped without extra handling, which seems like you
> >>> really don't need to know the number relabeled as much as whether it was
> >>> the number you expected, which seems like a point in favor of "pass the
> >>> expected count".
> >>>
> >>
> >
> > Sorry I accidentally sent this only to Daniel, adding back the list.
> >
> > With -v doesn't restorecon show what would be changed? Perhaps it
> > would be better
> > to add an option that produces some standard formatting for an audit
> > trail and that output
> > could include various statistics. Then folks could parse those
> > records. I see -p does some form
> > of progress/status meter as well, for whatever that is worth.
> >
> > <snip>
>
> My two cents FWIW is that being able to see whether you actually
> relabeled via exit status is way more useful than having to parse output
> to get at that info.  There's no need for the complexity of the wrapper,
> no opportunities for parser bugs, and you can just directly succeed/fail
> a systemd unit or bash script based on the return code.

How would someone distinguish between error and one file labeled? It's
also clipped to a very small
number, so will it really be useful on larger file systems?

We can simplify the output to stdout is just the number then no
parsing needed, albeit
we may want to look at the verbose option and define a format for that
as well (not now, future work).
So folks could do -vc or -c and have a way to get an audit trail of
files and a count independently.
The last line will always be the number in base 10 with a newline.
POSIX shells will strip that
in assignments from command substitution, so you can still just use
the number directly.

For -c:
set -e
x="$(restorecon -c)"
if x == 400; then
  whatever
fi

For -cv:
x="$(restorecon -cv | tail -n1)"
if x == 400; then
  whatever
fi