/sigh man 1 bash: Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by the remote shell daemon, usually rshd, or the secure shell daemon sshd. If bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but neither rshd nor sshd generally invoke the shell with those options or allow them to be specified. bash thinks it's being run remotely because we connect to the child over sockets. On 11/06/21 at 05:25pm, brainpower via pacman-dev wrote:
Hi,
recently I had very weird behavior when running pacman from an unprivileged user account using sudo compared to running `sudo -i` and then running pacman from the root user on one of my Arch Linux systems.
In the first case, post_upgrade, post_install or similar where NOT run, in the second case they ran fine. I was very confused by that, spent quite some time staring at pacman.conf, /etc/sudoers and /etc/sudo.conf comparing those to machines where this weird behavior did not happen and not spotting any differences...
I then had the idea to `strace -f` both cases, and found the following:
When running `sudo pacman ...` the bash process spawned by pacman to execute the install script reads and executes "/root/.bashrc" and I had some old leftover code in there which basicly did `exit 0` (my default shell is zsh, so that went unnoticed) thus exiting bash before it could execute the packages install script.
When executing pacman from a root shell (even when gained by `sudo -i` for example) the spawned bash does not source "/root/.bashrc". (Which is the behavior I'd expect, since it should be a non-interactive bash process, right?)
I've added a simple testcase below that shows both behaviors.
So, I guess in the first case bash considers itself to be interactive somehow even if it should not? I've got no idea how it could come to that conclusion... IIRC, one usually checks if stdin is a tty, pty or something like that and bash does indeed something like that if I read this correctly: https://git.savannah.gnu.org/cgit/bash.git/tree/shell.c#n523 Though having '-c' should even short-cuircuit that "if" to not even try to check for ttys. But maybe it does something weird later...
Also in _alpm_run_chroot() I see that stdin, stdout and stderr get closed and then connected to pipes, before execv() so they couldn't even be a tty or pty... or can they? But then they would have to be even when pacman is not run through sudo... I'd guess.
So I'm kind of stuck at figuring out why that happens.
Anyone of you seeing something I'm missing here?