Bug 1222140

Customer can modify their $PATH variables, to have /usr/bin , /bin, /sbin and /usr/sbin earlier than /usr/local (which is mounted via NFS). 

Btw. /usr/local is supposed to be used for LOCAL installation of software - and therefore NFS mounting is dangerous - it may break more stuff than just root login ( http://www.pathname.com/fhs/pub/fhs-2.3.pdf ). Maybe /opt is more suitable there.

However, can be adjusted in next coreutils update - although I tend to say this is not really a bug, full path is safer.

(although it is frequently used for sharing applications through NFS, of course - but as I said, with adjustment of PATH, root login delay should not happen)

Can you please file separate bug report for /etc/profile ? This one file is from setup package, not from coreutils - therefore I can't cover it with one bug report.

Ondrej,
I posted Bug #1228282.

All utilities from /etc/profile.d/ dir which belongs to coreutils package are typed with absolute path now.

Using package: coreutils-8.4-42.el6.x86_64

# egrep --color=always '(id|tty|tput|dircolors|grep)' -r $(rpm -ql coreutils | grep '/etc/profile.d/')
/etc/profile.d/colorls.csh:     #when USER_LS_COLORS defined do not override user
/etc/profile.d/colorls.csh:    if ( "`/usr/bin/tput colors`" == "256" ) then
/etc/profile.d/colorls.csh:if ( -f ~/.dircolors ) set COLORS=~/.dircolors
/etc/profile.d/colorls.csh:  if ( -f ~/.dircolors."$TERM" ) set COLORS=~/.dircolors."$TERM"
/etc/profile.d/colorls.csh:eval "`/usr/bin/dircolors -c $COLORS`"
/etc/profile.d/colorls.sh:#when USER_LS_COLORS defined do not override user LS_COLORS, but use them.
/etc/profile.d/colorls.sh:  for colors in "$HOME/.dir_colors.$TERM" "$HOME/.dircolors.$TERM" \
/etc/profile.d/colorls.sh:      "$HOME/.dir_colors" "$HOME/.dircolors"; do
/etc/profile.d/colorls.sh:      [ "x`/usr/bin/tty -s && /usr/bin/tput colors 2>/dev/null`" = "x256" ] && \
/etc/profile.d/colorls.sh:  eval "`/usr/bin/dircolors --sh "$COLORS" 2>/dev/null`"
/etc/profile.d/colorls.sh:  /usr/bin/grep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null && return


Old package coreutils-8.4-37.el6.x86_64:
# egrep --color=always '(id|tty|tput|dircolors|grep)' -r $(rpm -ql coreutils | grep '/etc/profile.d/')
/etc/profile.d/colorls.csh:     #when USER_LS_COLORS defined do not override user
/etc/profile.d/colorls.csh:    if ( "`tput colors`" == "256" ) then
/etc/profile.d/colorls.csh:if ( -f ~/.dircolors ) set COLORS=~/.dircolors
/etc/profile.d/colorls.csh:  if ( -f ~/.dircolors."$TERM" ) set COLORS=~/.dircolors."$TERM"
/etc/profile.d/colorls.csh:eval "`dircolors -c $COLORS`"
/etc/profile.d/colorls.sh:#when USER_LS_COLORS defined do not override user LS_COLORS, but use them.
/etc/profile.d/colorls.sh:  for colors in "$HOME/.dir_colors.$TERM" "$HOME/.dircolors.$TERM" \
/etc/profile.d/colorls.sh:      "$HOME/.dir_colors" "$HOME/.dircolors"; do
/etc/profile.d/colorls.sh:      [ "x`tty -s && tput colors 2>/dev/null`" = "x256" ] && \
/etc/profile.d/colorls.sh:  eval "`dircolors --sh "$COLORS" 2>/dev/null`"
/etc/profile.d/colorls.sh:  grep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null && return

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, 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://rhn.redhat.com/errata/RHBA-2016-0906.html