Local Community

Local fails to ask for admin credentials when updating hosts file

Support
#1

I’ve read through the posts of which I’m aware in the forums concerning hosts file issues, but cannot see this particular issue.

Issue in brief

On a Mac running OS X 10.11.6, when running LBF under a non-admin user account (i.e. a day-to-day working account per best security practice), LBF will only successfully ask for admin credentials to update the hosts file on the first occasion in each session. On all subsequent occasions in that session, LBF appears to attempt to update the hosts file using the current user’s credentials, which fails because the current user is not in the sudoers list.

System

Observed on 2 separate Macs, each running OS X 10.11.6 and Local by Flywheel 2.1.2.

Also observed running LBF 2.2.0 (pre-release) on the same system.

Other software

No anti-virus running.

Little Snitch installed but the issue persists whether or not Little Snitch is active.

OS X Firewall active but the issue persists if the firewall is disabled.

Desktop Server installed but not running. DS, when running, can successfully update the hosts file as necessary. DS sites use *.dev; LBF uses *.local

Steps to reproduce issue

LBF application installed by downloading and copying to /Applications folder. See later for attempt to resolve by reinstalling.

  • Attempt #1 - application was installed and configured under an Administrator account
  • Attempt #2 - application was installed and configured under a non-administrator account

Obviously, in both occasions I logged in to my day-to-day non-administrator account to attempt to use the app and create/modify sites.

Both the above produce the same results, i.e. the issue persists.

  • Login to a non-administrator account
  • Launch LBF and do one of the following:
    • Create a new site
    • Remove an existing site
    • Click the ‘Fix It’ button in the orange “Warning! Missing hosts entry. This site may be inaccessible.” banner.
  • LBF then:
    • Sends a notification via OS X Notification Centre saying: "Host Redirection - Local by Flywheel is requesting administrative privileges to modify your /etc/hosts file
    • Creates a pop-up saying "Local by Flywheel wants to make changes. Type an administrator’s name and password to allow this.
    • Accepts the Administrator’s username and password and proceeds with the new site/removing old site/fixing existing site
  • The site is then created successfully and the hosts file is modified appropriately
  • Next, attempt to do one of the actions again (create, remove or ‘fix’ a site)
  • LBF will then:
    • Send a notification again via OS X Notification Centre saying: "Host Redirection - Local by Flywheel is requesting administrative privileges to modify your /etc/hosts file
    • NO pop-up is created asking for admin credentials (I checked in other Spaces, behind other app windows, and so on)
    • A popup is created saying “Uh-oh! Could not update hosts file - Local ran into a problem when trying to update the hosts file. Please contact support if this persists.”
  • The new site is created (or existing site removed, as appropriate)
  • The hosts file is NOT modified.
  • In the case of a new site being created, the orange banner appears saying “Warning! Missing hosts entry. This site may be inaccessible.”
    • Clicking on the “Fix it” button simply causes the same two notifications above, i.e.
      • Another notification via OS X Notification Centre saying: "Host Redirection - Local by Flywheel is requesting administrative privileges to modify your /etc/hosts file
      • A popup saying “Uh-oh! Could not update hosts file - Local ran into a problem when trying to update the hosts file. Please contact support if this persists.”
  • This situation persists until the LBF is quit and relaunched

Attempted solutions / workarounds

  • Restarting an individual site does NOT solve the issue
  • Restarting the local machine from within LBF does NOT solve the issue
  • Restarting the Mac does NOT solve the issue
  • Completely uninstalling PBF and VB does NOT solve the issue
  • Repairing permissions (via terminal) does NOT solve the issue
  • The only workaround is to stop all sites, quit LBF and relaunch the application. You can then have one further successful new site/remove site/fix site attempt, before the issue occurs again.

Logs & Notes

It appears that, the first time PBF needs to modify the hosts file, it successfully asks for administrator credentials and proceeds with modifying the file as needed. On each subsequent occasion where the hosts file should be modified, it seems that although LBF sends a Notification that it has requested administrator credentials, in fact it hasn’t done so and attempt to modify the hosts file using the current user’s credentials.

Because the current user in this scenario is not an administrator, this attempt fails:

{ stdout: '',
  stderr: 'Brian is not in the sudoers file.  This incident will be reported.\n',

LBF seems unaware of this and reports a generic ‘problem’ with modifying the hosts file.

I have the log file if you’d like it.

Comments

Is this thing built on Electron? I only ask because this whole thing sounds very much like an ongoing issue with Atom, Brave and maybe other such software. With those, the only time they need admin credentials is to autoupdate the app itself, and there’s a known issue where the app will download the new version of itself, attempt to install it using the current user’s credentials (thus failing without notification), and the cycle endlessly repeats itself. The first the poor user tends to know is that they rapidly run out of disk space, as the aborted downloads sit in /private/var/folders and with ~400MB being added every few minutes it doesn’t take long to build up.

Looking forward to a resolution for this - I’d very much like to move over to LBF completely but this is sadly not possible at present.

#2

An update: it seems that this is definitely a LbF-asking-for-admin-permission issue, rather than anything specifically do to with the hosts file.

I say this because I have the same problem when LbF is supposed to ask for an admin password to trust an SSL Certificate.

Steps to repeat the issue

  1. Launch Local by Flywheel
  2. Carry out any action that requires administrator permission (create a new site, delete a site, etc.). This should be successful, because it’s the first time in that session that LbF needs to ask for Administrator permissions.
  3. Import a ZIP file containing a site with an SSL configuration.
    1. LbF will import the site, and report that there is an SSL present and ask if you wish to trust it
    2. The Notification Centre widget will claim that LbF is asking for administrator permission to trust the SSL
    3. However, there is no dialog box in which to enter administrator credentials (similar to original post above)
    4. LbF then attempts to approve the SSL certificate using the logged in user’s credentials, which fails because the user is not an administrator (again, same as above)

Do we have any updates on this issue at all from the Flywheel team?

#3

Hey Brian,

I really appreciate all of the details and steps to reproduce the issue!

Yup, Local uses Electron.

Unfortunately, Local doesn’t support running from non-admin accounts at this time. Is there a specific reason why you’re not using the primary account that ships with the Mac? If so, we can possibly look into supporting this in the future.

#4

@clay I run Local from a non-admin account and have done so since the beginning. Local has always asked for admin credentials when needed.

#5

Hi @clay

Thanks for the response.

(tl;dr - I suspect that lots of people will be trying to run Local as a non-admin. Might even explain some more of the issues on these forums to do with Hosts and/or SSL, IDK.)

I don’t want to open the entire can of worms about running as Standard vs. Admin for day-to-day use - I’ll leave that for the MacRumors forums :wink: - but essentially I’ve always used a standard account for everything day-to-day (along with other users of the Macs) and kept a separate Administrator account solely for those occasions when admin privileges are needed. Proponents will say it’s a security best practice for a few reasons, e.g. if a script manages to fool you into entering your user password it won’t do so much damage, and so on.

I know the security benefit of this was reduced a little by the introduction of SIP with 10.11, but it’s been standard procedure for me since the early days of OS X, and generally, to run day-to-day with the least privileges that you need and only elevate them when needed.

Regardless of who is right and wrong about that issue, every time I’ve seen a debate it usually ends up around 50/50, i.e. half of the people do recommend running day-to-day as a Standard account. So, that’s maybe up to half of the Local user base that could be adversely affected by this, notwithstanding folk such as @afragen above who doesn’t have the same issue for whatever reason(s).

I suppose the straightforward thing to do, if you don’t support running as a non-admin, is to simply have the app refuse to launch if a non-admin tries it. That would at least reveal the number of people who do use it like that, like @afragen , as no doubt they’d soon make themselves known on these forums. :slight_smile:

DesktopServer seems to get round this issue by simply running the whole process as an Administrator until it quits - that’s why you have the slightly odd double-launch thing where it relaunches after asking for Admin credentials, but at least it then doesn’t have to keep asking for credentials every time it needs to modify the /hosts file. Not sure if that’s an option for Local.

I know the failing-to-ask-for-admin-credentials issue seems to be an issue with Electron apps and I’m no programmer, but there have been posts on Electron forums, Git etc. for several years, so it’s not a new issue and I don’t know if it’s been fixed in recent releases. The only Electron based app that I use that doesn’t have the failing-to-ask-for-admin-credentials issue is VS Code, but I couldn’t tell you what that does differently to the rest.

Hope that helps.

1 Like
#6

@themustardseed the only caveat I’ll state is that I keep the Local app in ~/Applications. Not sure if it makes a difference.

#7

Ah, I got all hopeful then @afragen becuase that trick worked with Atom and it’s auto-update issue. But, sadly, not with Local, at least not on my machines. Thnaks for the tip, though.

#8

Sorry it didn’t work. If you have any questions about my environment LMK. Basically on a 11 inch MacBook Air running latest High Sierra in non-admin account. Local in ~/Applications to get auto-updating to work. I’ve always run under non admin account even if Local/Pressmatic was in /Applications.

1 Like
#9

@themustardseed,

Okay, so you’re good to go with the hosts file?

If Local isn’t auto-updating, try the commands in this post. Make sure you change /Applications to ~/Applications: [macOS] Help! Local isn’t automatically updating!

#10

Hi @clay - No, I think there’s some confusion here because my issue isn’t resolved. I still have Local by Flywheel failing to ask for Administrator credentials after the first request in a session.

So no, the hosts file isn’t good - that is one of the times when LbF should ask for Administrator credentials and fails to do so. Another is when asking the user to trust an existing SSL in an imported site. You’ve said above that you don’t support LbF on non-admin accounts and, as I mentioned, I suspect that is a lot of potential or actual users.

One other observation I can add is that this failing-to-ask-for-admin-credentials issue seems to reset itself after exactly 5 minutes.

So:

Scenario A

  1. Launch LbF
  2. Make a change requiring admin credentials (create new site, remove site, etc.)
  3. Flywheel correctly asks for admin credentials e.g. to modify hosts file
  4. Operation succeeds
  5. Within 5 minutes, make another change requiring admin credentials
  6. LbF says in notification centre that it’s asked for admin credentials, but fails to do so (no dialog box)
  7. Operation fails as current user doesn’t have required privileges

Scenario B

  1. Launch LbF
  2. Make a change requiring admin credentials (create new site, remove site, etc.)
  3. Flywheel correctly asks for admin credentials e.g. to modify hosts file
  4. Operation succeeds
  5. WAIT 5 minutes, then make another change requiring admin credentials
  6. Flywheel correctly asks for admin credentials e.g. to modify hosts file
  7. Operation succeeds

Hope that helps

Brian

#11

@clay I am also having this problem. What is the fix for this?

#12

I am also Running into this issue I am teaching students how to use wordpress and would like o use Local as a way of showing them how easy it is to get started and use to manage your wordpress site, but the student computers are all admin protected meaning that a student cant just create a site with Local with out updating the host file.

#13