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

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

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.

-Daniel