On Mon, Oct 02, 2017 at 05:07:01PM -0700, L A Walsh wrote: > That's fine w/me -- I was just concerned about a local DoS, if someone > could "pollute" the login stuff.
You'd have to be root, yes? > Hmm... there is a bash.bashrc in /etc.... Only if your OS vendor has built bash with that add-on. It is not part of the standard bash upstream build, nor is the pathname CONSISTENT across the various Linux distributions that use it. (Debian uses /etc/bash.bashrc and CentOS uses /etc/bashrc and so on.) In any case, it's under control of the local sysadmin (root). All this talk of login seems like a red herring to me. The issue that was reported is the inheritance of OLDPWD by noninteractive bash scripts (e.g. wrapper scripts that start web browsers), as well as interactive shells, which are not typically login shells. Changing the behavior of bash when invoked as a login shell (per Subject:) won't do anything to help the original poster, and I do not understand why it was prposed. I don't have a solution, but I can list out some options, and people may consider them, or laugh at them, or whatever. 1) Do nothing. Leave everything as it is. The OP solves their issue by aliasing startx to "cd / && cd && startx". 2) Have bash clear OLDPWD upon startup, always. 3) Have bash clear OLDPWD upon startup, if invoked as sh. 4) Have bash clear OLDPWD upon startup, if invoked noninteractively. 5) Have bash check whether OLDPWD is a directory only when the OLDPWD variable is actually used (either explicitly, or by cd -).
