On Sat, Jan 31, 2015 at 4:40 PM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 1/30/15 3:50 PM, Jonathan Hankins wrote: > > I agree about being able to use named pipes, etc. as HISTFILE. My > concern > > is that I think there may be a code path that leads to rename() and > > open(O_TRUNC...) being called on something that isn't a regular file. > > OK, say the history file is not a regular file. What negative scenarios > are possible if the history library opens that file with O_TRUNC > If the history code opens a block or char device file for append or truncate, and writes to it, it could destroy the underlying file structure. I can't think of any reasonable scenario where HISTFILE could be a block or char device, but like you said, named pipes could be useful. Maybe test the file with S_ISREG|S_ISFIFO. > > Furthermore, I think that if someone can manipulate a user's HISTFILE > > setting maliciously, there may be a code path to cause an unwitting > > overwrite of a file whose name ends in hyphen. > > If someone can manipulate a user's $HISTFILE setting, they can overwrite > any file the user has permission to write. It's always been thus. Right. My concern is that a potential exploit could inject a malicious value for HISTFILE into the environment. I think (but may be wrong) that HISTFILE is the only codepath in a default shell invocation that could result in a silent writing to an arbitrary file without direct action on the part of the user. Good security practices are the responsibility of the user, but I think it would be prudent to ensure that HISTFILE is, at least a regular file, or a pipe. -Jonathan Hankins -- ------------------------------------------------------------------------ Jonathan Hankins Homewood City Schools The simplest thought, like the concept of the number one, has an elaborate logical underpinning. - Carl Sagan jhank...@homewood.k12.al.us ------------------------------------------------------------------------
