Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix crash on failure to trim ~/.sh_history
@vmihalko writes: > We were able to reproduce an old issue mentioned in > https://bugzilla.redhat.com/show_bug.cgi?id=1885399 using the > latest version of ksh. The corresponding code has not changed > much in the past few years. > > To provide further explanation, the problem arises when a user's > .sh_history file grows to a size that triggers the hist_trim > function, but the user lacks (after the creation of .sh_history) > the necessary write permissions to their $HOME directory. As a > result, ksh becomes stuck in a recursive loop between the > sh_histinit(src/cmd/ksh93/edit/history.c#L203) function and the > hist_trim(src/cmd/ksh93/edit/history.c#L417) function. > > Conditions for reproduction: > > 1. The size of the .sh_history file is larger than the HIST_MAX > limit. (src/cmd/ksh93/edit/history.c, line 325) > 2. .sh_history file has not been changed in the HIST_RECENT > seconds (src/cmd/ksh93/edit/history.c, line 406) > 3. The user does not have permission to write to the $HOME > directory. src/cmd/ksh93/edit/history.c: hist_trim(): - Print a warning and return if unlink(2) fails. The warning tells the user to check the history file's parent directory is writable. This is the best I realistically do for now, because this function's basic method assumes a writable parent directory. - The temp file fallback is deleted because it's fundamentally flawed: it assumes the temp file is made on the same volume as the history file and can simply be rename(2)'d in place. Even on systems where this is the case, it doesn't appear to be working correctly, but this is not worth looking into. Resolves: #695
- Loading branch information