5 ms·
Personally, I like to see sqlite builds into the bash. For features such as: Continuous logging the bash commands, env, results, exec time in a sqlite data
by tkinom 5y ago
Personally, I like to see sqlite builds into the bash.
For features such as:
Continuous logging the bash commands, env, results, exec time in a sqlite database for security/auditing and regression testing.
The db file can be kept opened, no need to spawn a separate process for each command logged.
Anyone else interests in such approach. Anyone thinks of any potential issue for such integration?
If there are enough interests, I can start a open source project for this.
- chmaynard 5y agoInteresting idea. How would you add sqlite bindings to bash? Via a plugin?
- nerdponx 5y agoYou could do it in Zsh with a "module".
- tkinom 5y agoProbably something like the following: 1) Add sqlite_log.[ch] files to bash source repo. 2.a) Add sqlite_init_db(...) to init a database per bash_sqldb_{date}_{pid}.db per bash pid on ~user/.bash_db/ dir. 2.b) Add sqlite_log_cmd(...) to log the cmd, evn, pid, to the opened db. 2.c) have the bash command exec routine to call the sqlite_log_cmd(...) on each cmd execution. 3) Query, report of the commands execution will be handled outside with bash scripts/sub commands/web intf. * Should be very low overhead (micro-seconds) for each command. Now I think this out a bit more, maybe it is better to write ebpf script and pipe all the cmds exec to one centralized sqlitedb (instead of per user/pid and only for bash). Likely more useful from system security auditing POV, easier to extend by adding network connetions, file open, privilege escalation type events to the DB.