Re: Avoid sourcing bashrc when connected to sockets

[Chet Ramey]

On 2/21/22 1:31 PM, Andrew Gregory wrote:
> On 02/14/22 at 11:11am, Chet Ramey wrote:
> > On 2/13/22 2:55 PM, Andrew Gregory wrote:
> > > The pacman package manager runs install scripts by forking and invoking a
> > > compile-time configured shell by calling "<shell> -c '. <path-to-script>;
> > > <operation> <args>'", e.g. "bash -c '. /tmp/.INSTALL; pre_install pacman'".  A
> > > while back we switched from using pipes to sockets to communicate with the fork
> > > in order to avoid SIGPIPE problems.  Unfortunately, this makes bash think it's
> > > being run under rsh/ssh and it now reads ~/.bashrc, which can break scripts.
> > > Can the rsh/ssh check be modified to ignore this case?
> >
> > How do you tell "this case" from others?
>   
> No idea, but I'm only passingly familiar with the original intent of this
> behavior.

You can't. If stdin is a socket, and SHLVL is < 2, meaning this instance of
bash is not being run as a child of any other bash instance that exports
SHLVL (as it does by default), there's nothing to distinguish this case
from a bash being run directly by sshd.

> > You could start bash with the SHLVL environment variable set to something
> > greater than 2. That will inhibit sourcing bashrc even if bash thinks it
> > was run by ssh or stdin is a socket. Make sure to unset BASH_ENV as well.
>
> I had considered this, but wasn't sure how reliable manipulating SHLVL would
> be.  If that's going to be reliable behavior going forward though, that's
> probably the easiest option.

The check's been in there since 1999, so I don't see it changing. Just
don't set it to 999.

> > You might also want to tell your vendor about this, since they built bash
> > with the non-standard option that enables this behavior.
>
> Can you explain this?  Looking at the package build script[1] and the bash
> source, nothing stands out to me as specifically enabling this behavior.

I guess the socket connection carries the day. I made the assumption that
the package manager didn't carry SHLVL through the environment (since, if
it did, bash would have incremented it to at least 2), but did pass
SSH_CLIENT through (so the run_by_ssh check, if compiled in, would have
passed). But the socket connection will succeed even if the test for
SSH_CLIENT isn't performed.

--
``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/