sudo access proposed changes

[anantshri]

Issue raised earlier in homebrew but as suggested by homebrew folks Homebrew/legacy-homebrew#38509 raising issue here.

I have a setup where the user with brew setup doesn't have sudo access. While mac takes it gracefully by allowing a username as well as password prompt, brew assumes that sudo is enabled for user and the step fails after a long download of file.

Here are two options i am suggesting.

1. We check for sudo access before hand or via variable and don't download the file if sudo is needed when user does'nt have sudo access.
2. find a way to prompt a username and password to use for privilege elevation.

example if you install say virtualbox via brew then it need to install a couple of drivers which require them to have sudo access or i suppose any .pkg file is executed via installer with sudo permission. I hope this makes it a bit more clear. thats where we can make a check if the user doesn't have sudo why bother downloading the package. its just a waste of bandwidth and extra time.

[radeksimko]

Hi!
We're aware of this problem, and the issue below is the beginning of a possible solution:
#8819

Once we have the data about each cask, we could add something like --fail-without-su-perms (I believe someone will come up with better name) which will print an error message instead of downloading the cask?

e.g.

$ brew cask install virtualbox --fail-without-su-perms

Can't install virtualbox, su perms needed.

What do you think?

[anantshri]

why not inverted behaviour.

ie. we internally check if user has sudo access if not just print message that the cask need sudo not downloading.

Or we can investigate a possibility of asking user credentials simmilar to how osx ask's both username and password. and see if we can use those to perform installation. But in that case managing uninstall will be a big pain of its own.

[vitorgalvao]

we can investigate a possibility of asking user credentials simmilar to how osx ask's both username and password.

That’s easy to do but calls a GUI — which breaks automation — so it’s a no-go.

I agree with not needing a flag to specify this behaviour; it should work by default.

[anantshri]

I can understand the part about GUI and automation stuff and suggested only as a last alternative.

[radeksimko]

Or we can investigate a possibility of asking user credentials simmilar to how osx ask's both username and password.

That's basically what we do already, even though it's just a side-effect of 3rd party tools we use as those require su perms (typically install for pkgs).

Also it's worth pointing out that "sudo perms" is a relative term, because it really depends what you, as a user have access to. Some things are obvious, but some are not.

e.g. imagine a situation when /Applications/ has ownership your-username:staff and privileges rwx/rwx/---, so even though you're not su, you can install apps to /Applications because you're part of staff group. You may not be able to run install *.pkg though.

[vitorgalvao]

You example is a good point. Guess we might need that flag after all.

[vitorgalvao]

Seems like there isn’t much interest in this for now. With so much more stuff with higher priorities, I’ll close it. We can always revisit this later.