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

[Daniel Burgener <dburgener@linux.microsoft.com>]

On 11/13/2025 2:29 PM, William Roberts wrote:
> 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?

No, I agree with your concern about returning the number of files 
relabeled.  My suggestion was:

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

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

That may not strictly be "parsing", but it's still added complexity vs 
checking a return code.

-Daniel