Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Sos reporit
Version-Release number of selected component (if applicable):
# cat etc/redhat-release
Red Hat Enterprise Linux release 8.5 (Ootpa)
# rpm -q sos
sos-4.5.1-3.el8.noarch
How reproducible:
100% reproducible
Steps to Reproduce:
1. Run `sos report --clean`
2. Extract the /var/tmp/sosreport file generated
3. Find mac address inside various log files that is not obfuscated.
# find /sosreport..<remaining path> -type f -exec grep <MAC_Address> {} \;
Actual results:
MAC address is still found even when --clean was used.
Expected results:
All occurances of MAC address should be obfuscated.
Additional info:
On my test machine, Without obfuscation 12 occurrences found while using --clean removes only 6 of those.
Nice finding!
(In reply to Pranav Lawate from comment #1)
> ~~~
> # aa:bb:cc:dd:ee:ff avoiding ipv6 substring matches
> IPV4_REG = (
> 28 r'((?<!([0-9a-fA-F\'\"]:)|::)(([^:\-])?([0-9a-fA-F]{2}([:-])){5}'
> 29 r'([0-9a-fA-F]){2}(\'|\")?(\s|$)))'
> 30 )
> ~~~
>
> The data set to match the partition:
> ~~~
> link/ether 52:54:00:3a:b2:a1 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68
> maxmtu 65535
>
> 52:54:00:3a:b2:a1 dev virbr0 vlan 1 used 2479/2479 master virbr0 permanent
>
> ATTR{address}== '52:54:00:8b:f9:81', NAME="eth0" <---- Missed
> 
> The result of SIOCGIFHWADDR is type 1 52:54:00:8b:f9:81. <---- Missed
>
> 
> "net.interface.enp1s0.mac_address": "52:54:00:8b:f9:81", <---- Missed
> 
> entry=NULL-0000:02:00.0-eno3-52:54:00:8b:f9:81-igb↵ <---- Missed
> 
> <mac address='52:54:00:3a:b2:a1'/> <---- Missed
> ~~~
>
>
> The issue lies with `?(\s|$)` this only matches with whitespaces and end
> of line.
> If we modify it to
> `?(\/|\,|\-|\.|\s|$)` <-- Exclusively matching forward slash, comma,
> hyphen, fullstop along with blank space and End of line (NOT future proof)
> or
> `?(\D)` <--- Matching non-Digit patterns , matches with anything
> that isn't a digit including white space and End of line
> or
> `?(\W)` <--- Matching non-Word patterns , matches with anything that
> isn't a word including white space and End of line
The '?' applies to the preceding (\'|\"), meaning "address can be wrapped by either quotation mark".
What can (or cant) follow *after* an address? Just blank space or newline (like now) is not sufficient. Non-word (or on-digit) pattern isnt correct since it treats
The result of SIOCGIFHWADDR is type 1 '00:50:56:fd:51:40'x
as a match, while:
The result of SIOCGIFHWADDR is type 1 00:50:56:fd:51:40
as a non-match.
(how to test:
python3
import re
IPV4_REG = '((?<!([0-9a-fA-F\\\'\\"]:)|::)(([^:\\-])?([0-9a-fA-F]{2}([:-])){5}([0-9a-fA-F]){2}(\\\'|\\")?(\W)))'
re.findall(IPV4_REG, "The result of SIOCGIFHWADDR is type 1 00:50:56:fd:51:40", re.I)
)
The
> `?(\/|\,|\-|\.|\s|$)` <-- Exclusively matching forward slash, comma,
> hyphen, fullstop along with blank space and End of line (NOT future proof)
sounds to work well in all use cases I tested, though I dont like much the explicit enumeration of allowed characters. But it seems the best / working.
Jake, any preferences?
The biggest consideration here is to ensure that we continue to ignore substring matches within IPv6 MAC address strings. The only concern I have is matching on `-` characters, as sometimes mac addresses are written with dashes instead of colons - beyond that while it's not ideal, I don't have a better solution than the other explicit matches.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sos bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:4279
Description of problem: Sos reporit Version-Release number of selected component (if applicable): # cat etc/redhat-release Red Hat Enterprise Linux release 8.5 (Ootpa) # rpm -q sos sos-4.5.1-3.el8.noarch How reproducible: 100% reproducible Steps to Reproduce: 1. Run `sos report --clean` 2. Extract the /var/tmp/sosreport file generated 3. Find mac address inside various log files that is not obfuscated. # find /sosreport..<remaining path> -type f -exec grep <MAC_Address> {} \; Actual results: MAC address is still found even when --clean was used. Expected results: All occurances of MAC address should be obfuscated. Additional info: On my test machine, Without obfuscation 12 occurrences found while using --clean removes only 6 of those.