From: https://github.com/neutron37/susudoio/issues/1#issuecomment-384611430 https://github.com/neutron37/susudoio/issues/1#issuecomment-... I decided not to bo

From: https://github.com/neutron37/susudoio/issues/1#issuecomment-384611430 https://github.com/neutron37/susudoio/issues/1#issuecomment-... I decided not to bother with sanitizing bash history and to remove the admin-pass argument "feature" entirely (See https://github.com/neutron37/susudoio/issues/9 https://github.com/neutron37/susudoio/issues/9). First of all, sanitizing bash history wouldn't be enough. The CLI password argument also leaks in other ways. For example, the listing of commands via `ps` would show the password for as long as the commend executes. It's also likely that the command would be logged to disk (or even to network!) depending on the system's configuration. I made an effort at sanitizing bash history out of curiosity. Here's what I found. The session history is stored in the bash processes memory until the end of the session, during the shutdown sequence of the process it's flushed into ~/.bash_history. So, the only crazy, horrible way that I could think of to clear the _active_ session's history is to do the following: 1. Escalate to root within susudoio 1. Hijack the tty which spawned bash (which, in-turn, spawned susudoio) 1. Background susudoio 1. Selectively clear the bash history with `history -d $badline` 1. Foreground susudio 1. Return to normal execution Ew. That's disgusting! Hijacking the TTY session of another user (even as root) is nasty. You have to things like change permissions on file-descriptors which should never have their permissions changed. Any reliable method for this will likely leverage tools which are meant for invasive debugging and/or penetration, so probably shouldn't be installed on your "secure" system Circumventing the in-built security of my OS in the name of security seems... pointless. Won't fix!!!