1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it
2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
The assumption is that you deal with non-malicious users who just make mistakes (which is often the case).
for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
In case you didn't know, you can invoke an editor from within less by pressing 'v'. And that wouldn't get registered in the shell history ;)
It was there previously? Sorry I missed it. In any case, I wouldn't call the action I mentioned malicious. There is no hack involved, no improvisation either. Simply using a built-in feature of `less`.
Thanks for your reply! Since I do a lot of devops I've tried over the years to formulate a mental model of how a sysadmin thinks and what they care about. I'd never have thought about this auditability concern, so it's something to add to my list! :-)
1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it
2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
The assumption is that you deal with non-malicious users who just make mistakes (which is often the case).