> it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running.
No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged.
Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?
> if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to.
If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.
No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged.
Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?