rule 6.2.4 with login banners

[antonatos]

in one of the servers the /etc/profile has this block (full banner not displayed here):

# banner

echo -e "\e[34m
   ,e#####me        ,e######m,         ,a###########O     ##h       /e#######mJ

[=] Server : $HOSTNAME
[=] IP     : $(ifconfig | grep '192' | head -n1 | awk '{print $2}')
[=] Kernel : $(uname -r)
[=] Uptime : $(uptime | awk '{print $3 $4}')

Welcome back $USER
"

which causes the rule 6.2.4 evaluation to be confused since the dot_in_path is wrong and results in creating multiple files due to stdout registration:

[root@test-deploy ~]# /bin/bash --login -c 'env | grep ^PATH=' | sed -e 's/PATH=//' -e 's/::/:/' -e 's/:$//' -e 's/:/\\n/g'

   ,e#####me        ,e######m,         ,a###########O     ##h       /e#######mJ

[=] Server \n test-deploy
[=] IP     \n 
[=] Kernel \n 3.10.0-1160.25.1.el7.x86_64
[=] Uptime \n 1\n04,2

Welcome back root

/opt/kafka/bin\n/usr/local/bin\n/opt/kafka/bin\n/usr/local/bin\n/usr/local/sbin\n/usr/local/bin\n/usr/sbin\n/usr/bin\n/root/bin\n/root/bin

An extra "grep "^PATH" before the sed commands seems to fix the issue

[uk-bolly]

hi @antonatos

We wanted to reach out after looking over the issue and we have some questions. Would you be able to give us some detail on your /etc/profile? Looking at the changes suggested they do work, however they might deviate from some best practices, we would normally find the sort of setting you have in a profile.d script. If they are placed within /etc/profile.d, we don’t see the issue you are experiencing. At this time we are leaning towards this being something that is better addressed in your environment. However before we make that call we would like to take a poke at what you are using, so we can address as many options as possible without impact.

Thanks

uk-bolly

[antonatos]

Hi, I attach the /etc/profile file as found in one of the servers. You are true it does not happen if the contents are in /etc/profile.d but I put the issue up in case you want to guard against edge cases.

On 6 May 2021, at 8:57 PM, uk-bolly ***@***.***> wrote: hi @antonatos <https://github.com/antonatos> We wanted to reach out after looking over the issue and we have some questions. Would you be able to give us some detail on your /etc/profile? Looking at the changes suggested they do work, however they might deviate from some best practices, we would normally find the sort of setting you have in a profile.d script. If they are placed within /etc/profile.d, we don’t see the issue you are experiencing. At this time we are leaning towards this being something that is better addressed in your environment. However before we make that call we would like to take a poke at what you are using, so we can address as many options as possible without impact. Thanks uk-bolly — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARD3BQ4EOBG2PKBAKZ4UTTTMLKAVANCNFSM44CW33KA>.

[profile.txt](https://github.com/ansible-lockdown/RHEL7-CIS/files/6436929/profile.txt)

[uk-bolly]

Hi @antonatos

Thank you for your patience. Before making the decision, we have been waiting to see if anyone else has requested this either from the community or from our direct clients and we have not seen this appear again.
While it is very valid point there are many ways that people may be achieving their requirements and trying to allow for all the options and ways of achieving this is not something we could handle in each case.

However in this case, I have raised the PR as we are certain this is not an uncommon practice and it will be seen again.

Many thanks once again

uk-bolly