Re: Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/28/24 6:18 PM, Gioele Barabucci wrote:
> On 28/04/24 22:50, Chet Ramey wrote:
> > On 4/28/24 3:07 PM, Gioele Barabucci wrote:
> >
> > >      $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
> > > /proc/$$/exe; head -1z /proc/$$/cmdline; echo'
> > >      /bin/bash
> > >      /usr/bin/bash-static
> > >      -bash-static
> >
> > So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
> > and internally sets shell_name to "bash-static" and login_shell to 1
> > (which notes that bash was executed with argv[0][0] == '-').
> >
> > Then when you get to setting $BASH, this code gets executed:
> >
> >    if ((login_shell == 1) && RELPATH(shell_name))
> >      {
> >        if (current_user.shell == 0)
> >          get_current_user_info ();
> >        name = savestring (current_user.shell);
> >      }
> >
> > which has been the way bash has behaved since the bash-1.x days. Is
> > this enough of an issue to change behavior that dates back that far?
>
> The bash manual defines $BASH as follows:
>
> > Expands to the full filename used to invoke this instance of bash.
> So, either the code or the manual should be changed.
>
> I see why changing such an old behavior for the sake of correctness may not 
> be worth the risk of breaking somebody's workflow. But at the same time it 
> is hard to believe that anybody may be relying on "$BASH contains the user 
> shell set up in /etc/passwd when read from a login shell".

I think the original intent of this code -- it was a very long time ago --
was that a login shell either came from login/getty/xterm or su. If it came
from su, the name in argv[0] was either "-su" (the traditional behavior of
`su -'/`su -l') or the user's login shell. The Linux-specific business of
specifying the shell to use didn't come along until much later. Non-Linux
systems still put "su"/"-su" in argv[0].

In that light, it's easy to see what's happening. You want to change "-su"
to something reasonable, and the user's login shell is what su always uses.
If it's already the login shell, no loss.

I think we can fix this Linux issue by checking for and changing "-su"/"su"
to the login shell and letting other pathnames through.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature