@xiangce

Thanks for pointing that out. I thought I included both the examples (which I did initially) but then I removed it to test each line individually. Finally I forgot to include the second example. My bad!

I researched a bit and found that this strange user-group occurs when the sssd/krb5 DOMAIN/REALM is configured. From what I observed the owner is domain users followed by the @ and DOMAIN name (CR.LOCAL in the example). Hence under the assumption that the group will always start with users in the subsequent commit I am checking if the 4th-index startswith() users. Hopefully this should take care of the user-group issue for both the scenarios.

As to not break the current convention I am storing domain as an owner and rest as the group.

Maybe it's possible to consider another overall reconstruction plan, e.g. the insights.parsers.parse_fixed_table.
It's just my thoughts, you may have a better resolution.

Yeah! I agree that anything new in the ls_parser is not easy to implement especially when we have to parse different elements depending upon the generic and SElinux context. I thought of using parse_fixed_table initially but gave-up eventually because before passing the data to parse_fixed_table it has to be cleaned for table and it still has to parse different numbers of columns based on the generic and SElinux context.

@psachin

I researched a bit and found that this strange user-group occurs when the sssd/krb5 DOMAIN/REALM is configured. From what I observed the owner is domain users followed by the @ and DOMAIN name (CR.LOCAL in the example). Hence under the assumption that the group will always start with users in the subsequent commit I am checking if the 4th-index startswith() users. Hopefully this should take care of the user-group issue for both the scenarios.

From this official guide document Adjusting how SSSD interprets full user names, it seems that "user" is just an example used in the doc. And I did a bit of research by using the RAT tool and found it's true and different usernames can be used in the group in the SSSD cases. For example:

/var/log:
total 3834048
drwxr-xr-x. 11 root             root                            4096 May 17 03:10 .
drwxr-xr-x. 20 root             root                             281 Nov 15 15:42 ..
-rw-------.  1 root             utmp                           19200 Apr 30 22:45 btmp-20220501
drwxr-xr-x.  2 chrony           chrony                             6 Jan 10  2019 chrony
-rwxrwx---.  1 [email protected] it [email protected]        56337 May 17 03:15 cron
-rwxrwx---.  1 [email protected] root                          196293 Apr 24 03:40 cron-20220424
-rwxrwx---.  1 [email protected] it [email protected]       194961 May  1 03:09 cron-20220501
-rwxrwx---.  1 [email protected] it [email protected]       194926 May  8 03:20 cron-20220508
-rwxrwx---.  1 [email protected] it [email protected]       195355 May 15 03:13 cron-20220515
-rw-r--r--.  1 root             root                          101107 Apr 23 04:02 dmesg

and

/var/log:
total 571780
-rw-------.  1 root   root                       0 May  8 03:37 spooler-20220515
drwxr-x---.  2 sssd   sssd                    4096 Apr 22 03:17 sssd
-rw-------.  1 root   gls-int-linux team  35607509 May 17 02:05 sudo.log

So, things become more complex ... maybe it's time to think of another resolution.

Can one of the admins verify this patch?

Closing due to it won't fix the issue.