On 2019/11/25 12:02, Chet Ramey wrote:
> On 11/24/19 7:35 AM, Ulrich Mueller wrote:
>> Description:
>> In a non-interactive non-posix-mode shell, saving the output of
>> "shopt -p -o" and restoring it will unset the expand_aliases option.
>>
>
> It seems like setting posix mode when it's already set, or unsetting it
> when it's not, should be a no-op instead of guaranteeing a certain
> environment (posix or default). That's easy enough.
>
Agreed
> There's no question that setting posix mode should change the values of a
> number of bash options to produce a compliant environment.
>
> It's a different question whether or not unsetting posix mode should revert
> to the settings before posix mode was enabled or restore the default
> environment. It's always meant the latter.
>
----
It is a bug because it is a logical design flaw / inconsistency.
It is clear that if POSIX is being toggled off, then the script has
already altered the environment from the default.
To be consistent with re-initializing the settings changed in POSIX
mode, to bashes default, then it would make sense to do so completely --
I.e.
clear the environment and re-initialize bash to its starting state.
If that seems unproductive to the point of being ridiculous, then what
settings, and environment is it ok to reset to some ill-defined half-way
state? To be productive, you want to have bash be returned to well defined
state as set by the user before POSIX mode was entered, OR, if POSIX mode
was entered when bash started, then there would be no previous state to
return to and the settings would be left alone and not arbitrarily changed
to some mix of POSIX/non-POSIX settings.
I.e. while POSIX has a set of required features, BASH has no POSIX
mandated set of features that must be changed to some arbitrary set of
non-POSIX compatible features.
To reiterate what would be reasonable to expect:
1) if the user started in bash-state and set bash's options to some
non-default state, that should be established as the non-posix
operational baseline such
that if something would cause bash to enter into a posix-state, say a
script sets
such a state in a function, and then tries to exit to the previous
state, the
user's environment would be completely unaware of the new state if it wasn't
the same state prior to the function's "excursion" into posix-state.
Thus to
maintain a script-environment's previous state, a return to bash-state from
posix state should always restore what was in place before hand.
Not doing so would open up a bash script to unexpected behaviors.
Compare
this with linux capabilities not being reset to their prior state after
a change
of user id. I argued with Ted Tso that this was a security bug waiting
to happen
while he maintained that I didn't know what I was talking about and that he
implementation was required by the final posix draft spec on
capabilities. I
said it was nonsense -- that it was a basic, fundamental programming flaw
not to restore the environment to the previous state before the capability
altering program had been run.
He shook his head and proceeded to ignore me.
Some number of weeks later, this bug was hit by sendmail trying to
use capabilities to reduce privilege, but instead left the system with the
higher level capabilities in place -- and exploit that had capabilities
removed
from the kernel for the next four+ years. Ted Tso moved that I should be
banned from the linux kernel summit in a few weeks as I was "dangerous" he
said to my boss. It was convenient for my boss to play good dev/bad dev and
cast me as the bad dev, to ingratiate himself and later be allowed to
implement and integrate his own security module (SMAC) into the kernel as
sgi's importance in trusted linux or 'tlinx' was killed with my exit.
Now about not restoring the previous environment when exiting POSIX
mode,
is that really a good idea?
2) If Posix ran from the beginning, then there are no settings to return to
in which case, no settings should be changed when posix mode is
disabled/exited.
I don't see a problem with those behaviors, but adopting unexpected
behaviors
upon leaving a POSIX mode? Doesn't seem good practice.
-l
