RhetTbull / locationator

A simple macOS menubar app that provides access to the macOS Location Services reverse geocoding API via a local web server as well as a command line tool.
MIT License
17 stars 0 forks source link

CLI not installed on non-admin user #10

Closed gspannu closed 8 months ago

gspannu commented 8 months ago

CLI tools cannot be installed from the menu item if the macOS user is a non-administrator (i.e. a regular user).

v0.0.6

I guess, that access to /usr/local/bin requires sudo access, hence it fails...

Screenshot 2023-10-17 at 8 27 36 am

I temporarily fixed this by sudo cp /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin

RhetTbull commented 8 months ago

OK, will see what I can do but this may not be worth the time. macOS makes this sort of thing so difficult. I included the appropriate admin permission with the app but not sure why it didn't get triggered to prompt the user.

gspannu commented 8 months ago

OK, will see what I can do but this may not be worth the time. macOS makes this sort of thing so difficult. I included the appropriate admin permission with the app but not sure why it didn't get triggered to prompt the user.

You are correct, it may not be worth the time trying to fix it (if it doesn't get fixed quickly).... As said earlier, there is a manual workaround anyway...

Great work... thanks.

RhetTbull commented 8 months ago

I added a note to the README about the CLI. A few thoughts:

  1. Currently, Locationator installs the CLI by copying a file to /usr/local/bin. It would be better to create a softlink to the binary so that upgrading the app also upgrades the CLI target without requiring the CLI be re-installed.
  2. I don't think there's any way to fix the install problem without granting full disk access which requires manual user steps in the Privacy settings. Even then, it might fail if another user owns /usr/local/bin. This is also a problem on multi-user homebrew installations where one user installed homebrew and another user tries to use brew which fails without su ORIGINAL_USER.
  3. Another alternative might be installing to ~/.local/bin and ensure that's in the path. This would require modifying .zshrc and I hate it when other apps do that. And it would fail if user is using a non-default shell.
  4. Finally, an alternative that's less elegant than "Install this for me" but more robust is to create a separate locationator-cli app in its own repo that can be installed with pipx install locationator-cli for example.
RhetTbull commented 8 months ago

If there was an open source example native macOS app that installed something in /usr/local/bin that would be a good reference to see how they solved this. VS Code is one such example but I searched their source for any hints and came away with nil.

RhetTbull commented 8 months ago

An alternative might be just to pop up a dialog box asking the user to copy the shell commands needed to the clipboard (to create /usr/local/bin if it doesn't already exist and symlink the CLI to the App bundle)? They could then paste these into Terminal, hit Return, type in password and be done.

gspannu commented 8 months ago

An alternative might be just to pop up a dialog box asking the user to copy the shell commands needed to the clipboard (to create /usr/local/bin if it doesn't already exist and symlink the CLI to the App bundle)? They could then paste these into Terminal, hit Return, type in password and be done.

Symlinking the CLI would be the best option… Option 1 in your previous post is the simplest option.

I agree… Just give the user a pop-up message to run the (copied to clipboard) command in Terminal. Simple, no errors, and updating the app will also update the CLI. Sounds like a good plan.

RhetTbull commented 8 months ago

I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.

gspannu commented 8 months ago

I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.

You are correct... that is a common issue.

The only way around this is to first do su admin (or whatever the administrator username is) and then run all commands as sudo

That is what most users would need to do (who are non administrators)... I think if you just put the message in a pop-up to state that users need to create a symlink to the /Applications/....locationator and create this in a folder which is in their PATH statement (e.g. /usr/local/bin or /opt/homebrew/bin or similar)

I think a pop-up message that shows an example command line for /usr/local/bin will suffice...

gspannu commented 8 months ago

I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.

You are correct... that is a common issue.

The only way around this is to first do su admin (or whatever the administrator username is) and then run all commands as sudo

That is what most users would need to do (who are non administrators)... I think if you just put the message in a pop-up to state that users need to create a symlink to the /Applications/....locationator and create this in a folder which is in their PATH statement (e.g. /usr/local/bin or /opt/homebrew/bin or similar)

I think a pop-up message that shows an example command line for /usr/local/bin will suffice...

You may be able to do this via AppleScript...

The following command in AppleScript works, and it prompts for a admin username/ password. do shell script "sudo ln -s /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator" with administrator privileges

RhetTbull commented 8 months ago

You may be able to do this via AppleScript...

That's a good idea. I'll give this a try to verify the prompt works when called from the compiled app

RhetTbull commented 8 months ago

Making progress....applescript runs and displays authentication dialog but does not execute correctly when run from the App bundle.

Screenshot 2023-10-19 at 10 43 53 PM
gspannu commented 8 months ago

Making progress....applescript runs and displays authentication dialog but does not execute correctly when run from the App bundle.

Screenshot 2023-10-19 at 10 43 53 PM

This command executes from the shell... osascript -e 'do shell script "sudo ln -s /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator" with administrator privileges'

You could also maybe place the commands in a text file, e.g. copyfiles.scpt (and then place this file within the app bundle) and then execute the command via osascript, something like... osascript ./additionalfiles/copyfiles.scpt

RhetTbull commented 8 months ago

This command executes from the shell...

Same command I'm running from AppleScript. The script runs, it's a permission issue...macOS is blocking the elevated permissions. Apple has tried to make this impossible.

RhetTbull commented 8 months ago

The authorization succeeds...but the script doesn't have access and just fails

default 05:56:33.837652-0700    authd   UID 501 authenticated as user X (UID 501) for right 'system.privilege.admin' 
default 05:56:33.837781-0700    authd   Validating credential X (501) for system.privilege.admin (engine 7476)
default 05:56:33.842010-0700    authd   credential 501 is member of group admin (does satisfy rule) (engine 7476)
default 05:56:33.842282-0700    authd   Succeeded authorizing right 'system.privilege.admin' by client 
'/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app' [81164] for authorization created by 

'/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app' [81164] (13,0) (engine 7476)

gspannu commented 8 months ago

Why not just show a pop-up message with the complete osascript command and copy-to-cliopboard and request user to run it.

I don't think this is worth your time to make it super elegant... I understand as a programmer, you want to !

RhetTbull commented 8 months ago

I don't think this is worth your time to make it super elegant...

I code as a hobby and get focused on interesting problems...this is, at the moment, an interesting problem. :-)

It looks like the sh that gets run is sandboxed and can't see /usr/local/bin:

Locationator 0.0.6 /bin/sh: ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory

gspannu commented 8 months ago

...this is, at the moment, an interesting problem. :-)

I can relate to that ... 😊

gspannu commented 8 months ago

It looks like the sh that gets run is sandboxed and can't see /usr/local/bin:

Locationator 0.0.6 /bin/sh: ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory

Just a thought... (and you have likely already checked this).

Did you run the command using sudo... as the Admin user may still require sudo access.

Locationator 0.0.6 /bin/sh: sudo ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory

RhetTbull commented 8 months ago

Yes, tried both with / without sudo

RhetTbull commented 8 months ago

I give up (for now), added your "copy osascript command to clipboard" idea and verified it works. Pushing a new release then will turn to the service. I still want to find a way to create the proper background helper in python that can do the privelleged install. Requires Service Framework and XPC and bunch of other pain....thanks Apple!

cfc62 commented 8 months ago

Hi folks! Funny I should find a completely different need to reverse geocode potentially solved by an Apple service meant for photos...

In any case, I'd love CLI access for what I'm doing and yes, I ran into the issue(s) above, even as admin. I can manage to write up some code work queries via the web server but I'd rather not.

For both free and paid reverse geocoding services, there's usually a limit imposed. For what I'm looking to do, I may hit that, and if so I'll report back (in another thread of course).

RhetTbull commented 8 months ago

Did you try the latest release which has you copy commands into the Terminal for installing the CLI?

cfc62 commented 8 months ago

I did, and still had issues until I realized that at some point I lost sudo permissions, even though I was admin.

Once I fixed that by re-enabling root (with Directory Utility of all things), the workaround worked.

It's working as expected now, appreciate it!

gspannu commented 8 months ago

Did you try the latest release which has you copy commands into the Terminal for installing the CLI?

Yes, the command line tool works with the latest version... and installed the CLI successfully. It prompted for a admin username/password (as expected).

RhetTbull commented 8 months ago

I'm moving on to the next project...I think the current install/uninstall works well enough though it's not elegant. Closing this issue.