sudo timestamp reset may break scripts about brew HOT 6 CLOSED

Duplicate of #17905, WONTFIX sorry.

from brew.

Thanks for continuing the conversation.

• brew should restore sudo access for ensuing processes, even if it blocks it for itself.

@bhavanki If you can provide details (ideally a pull request) for how this is technically possible: we'd love that. We haven't been able to figure out how to do this yet.

Yeah, I doubt access can be restored (especially if you all haven't discovered how to). With some further experimenting, I did find a workaround for leaving access in place. It works because sudo caches credentials by user and by TTY, so if the brew command runs in its own TTY, it can freely do away with any inherited access (in fact, I think it never gets it).

This Stack Overflow answer proposes using the script command for this purpose, and it seems to work. I created this shell function to call instead of brew in my own script.

brew() {
  script -q /dev/null "$(command -v brew)" "$@" | sed 's/\r//g'
}

(This is for macOS. Also, the script command seems to emit rogue carriage return characters, hence the sed usage.)

I don't imagine that this exact mechanism could work in brew, but maybe something else adjusting the TTY might. Anyway, hopefully this will solve the problem within my own script.

And, just for completeness: Ansible lets you supply a "become" password which is equivalent to prompting for sudo. It's an extra prompt for the user, but lets Ansible run steps requiring sudo without requiring it to be established ahead of time. It's probably the "right" way anyway.

• The problem is in formula privilege escalation, but the removal of sudo occurs for any execution of brew.

Almost all executions of Homebrew (not just installs) may require reading potentially untrusted Ruby code. It's hard to scope this much more tightly than it is currently, unfortunately.

Ah, understood, that's too bad!

from brew.

Thanks @bhavanki!

from brew.

This recent PR introduced the new behavior. #17694

from brew.

I understand the reason for the change. However, IMO this new behavior is an overreach.

• The problem is in formula privilege escalation, but the removal of sudo occurs for any execution of brew. The scope of the fix is too broad. (Reducing the scope wouldn't fully fix this problem, to be fair.)
• An executable should not alter its calling environment as a side effect. brew should restore sudo access for ensuing processes, even if it blocks it for itself.

from brew.

• brew should restore sudo access for ensuing processes, even if it blocks it for itself.

@bhavanki If you can provide details (ideally a pull request) for how this is technically possible: we'd love that. We haven't been able to figure out how to do this yet.

• The problem is in formula privilege escalation, but the removal of sudo occurs for any execution of brew.

Almost all executions of Homebrew (not just installs) may require reading potentially untrusted Ruby code. It's hard to scope this much more tightly than it is currently, unfortunately.

from brew.