Homebrew-cask: Moving Caskroom from HOMEBREW_REPOSITORY to HOMEBREW_PREFIX - Permission denied

[reitermarkus]

Since this issue bit a lot of users in the last days, instead of opening a new one, please comment on this one if the following fix does not work for you:

First of all, this problem _should_ only happen if you followed the instructions from brew update to sudo chown root:wheel /usr/local.

1. Temporarily set the permissions on /usr/local:

bash sudo chown $USER /usr/local

1. Rerun the brew cask command that failed.
2. You may now optionally change the permissions on /usr/local back:

bash sudo chown root:wheel /usr/local

This issue was first raised in https://github.com/caskroom/homebrew-cask/issues/24638.

[vitorgalvao]

We haven’t used the chief bug label in a while. This one deserves it.

[MikeMcQuaid]

@reitermarkus A suggestion: check if HOMEBREW_PREFIX is writable and if not print the message telling people what to chown.

[DasKeyserSoze]

was directed to this issue from #24819, but I am still experiencing the same issues identified in #24819 even after following instructions/suggestions indicated here.

I notice now that I am getting the same errors for any install attempts, not just applications that were previously installed.

[alexchandel]

I ran into this issue as well. What was the justification for moving the Caskroom? Doesn't it mean that merely installing homebrew-cask now requires sudo?

[jawshooah]

Doesn't it mean that merely installing homebrew-cask now requires sudo?

That has almost always been the case, except for a very short window when we had the Caskroom in HOMEBREW_REPOSITORY. Requiring sudo for install _by default_ is nothing new.

That said, you can still change the location of the Caskroom by adding --caskroom=/path/to/Caskroom to your HOMEBREW_CASK_OPTS environment variable if you are sudo-averse.

[vitorgalvao]

In truth, I actually liked that we stopped requiring sudo. But the more I think about it, the more I can see points in favour of both cases.

Having everything inside of Homebrew (the directory) makes /usr/local just a bit cleaner, does not require sudo, and it makes some sense to have Cellar and Caskroom together. On the other hand, both projects do behave differently and install different types of apps in different ways, so having Caskroom separate from Homebrew also makes some sense.

There’s also the matter of user experience. Installing Homebrew is something big we’re doing, so sudo seems acceptable. On the other hand, a user typing brew cask install google-chrome the first time and being prompted for the sudo password seems a bit weird (the former was explicitly a setup process, unlike the latter, though this all goes out the window when installing pkgs).

Considering the breakage having Caskroom inside Homebrew (due to the recent move) caused, I think it’s sensible to have Caskroom outside Homebrew. In the future, though (say a year or two, when most people have migrated to the new system and don’t have lingering app symlinks), I wonder if it won’t make more sense to go back inside Homebrew.

Either way, I’m ready to close this when anyone else is. It seems to be mostly resolved and pretty quickly contained (thank you for that).

[MikeMcQuaid]

Having everything inside of Homebrew (the directory) makes /usr/local just a bit cleaner, does not require sudo, and it makes some sense to have Cellar and Caskroom together. On the other hand, both projects do behave differently and install different types of apps in different ways, so having Caskroom separate from Homebrew also makes some sense.

Both the /usr/local/Homebrew and the /usr/local/Caskroom migrations require you to have ownership of /usr/local at the time of the migration.

In the future, though (say a year or two, when most people have migrated to the new system and don’t have lingering app symlinks), I wonder if it won’t make more sense to go back inside Homebrew.

I don't think it would. If it was to go to anywhere I'd suggest somewhere inside /usr/local/var/homebrew. /usr/local/Homebrew is purely a repository and we've worked pretty hard to avoid storing any data or state in there.

On the other hand, a user typing brew cask install google-chrome the first time and being prompted for the sudo password seems a bit weird (the former was explicitly a setup process, unlike the latter, though this all goes out the window when installing pkgs).

I agree here although longer-term I'd rather see Homebrew Cask where possible ask the user to run the sudo command rather than doing it for them. That removes the possibility of environment or parameter injection allowing another script to use Homebrew Cask as a privilege escalation vector.

[alexchandel]

I agree here although longer-term I'd rather see Homebrew Cask where possible ask the user to run the sudo command rather than doing it for them. That removes the possibility of environment or parameter injection allowing another script to use Homebrew Cask as a privilege escalation vector.

I'm more wary of this. The Homebrew install runs sudo for you. I'd rather have Cask use sudo for some small, discrete operation, than run brew cask as sudo and accidentally make my config files owned by root or something.

[MikeMcQuaid]

than run brew cask as sudo and accidentally make my config files owned by root or something.

That's not what I'm suggesting. I'm saying rather than cask running sudo command arg it instead aborts and tells the user to run sudo command arg.

[vitorgalvao]

I think if we do that, we’ll never hear the end of people asking for the old behaviour back. Though I understand your concern, we’d constantly be aborting users’ comands. Not forgetting that the commands to run can be a bit obtuse, and it’s a place for users to copy and paste wrongly and having nefarious results. It would also make diagnosing harder. Just thinking about it, the frustration is palpable.

We’re a downloader/installler with limited capabilities, we don’t have the luxury to not run sudo by choice (or we’d chose it). For the most part, we’re bound to each app developer’s choice of implementation.

We had plans (thinking mostly of people who do not have sudo access) for a flag that would abort commands that required sudo. In the end, that was scrapped for lack of interest.

We can certainly think of reinplementing that, but making it the default would just serve to annoy users. Just like when we had ~/Applications as the default directory most people used /Applications.

[vitorgalvao]

We haven’t had reports of this in a while.