I was wondering if one of you might be able to lend me a hand with something. I need to use terminal commands with Keyboard Maestro so that every time my Mac is unlocked, the following commands run automatically:
sudo chown -R mac:staff /Library/Audio/Plug-Ins
sudo chmod -R 755 /Library/Audio/Plug-Ins
This is what keyboard Maestro engine log shows:
Action 16141838 failed: Execute a Shell Script failed with script error: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
I'd really like to set it up so that it runs entirely in the background without asking for a password.
I should mention that this commands works perfectly fine from the terminal itself.
I'm not sure KM can remove the requirement for passwords for sudo. In macOS, there is a way to remove the password requirement for sudo, but that could be risky. Are you willing to remove the requirement for a password, or do you really need KM to enter the password for you?
Bear in mind, the password would have to be stored in KM, which is also not particularly secure. Both ideas have security issues. Are you willing to take the risk?
Is it possible to remove the password requirement for sudo only for this command?
I'm curious about the risks involved—what could possibly go wrong? I'm not traveling or sharing my Mac with anyone, and I'm the only one who uses it. Plus, my Mac need to be unlocked with password in order to use the terminal, so could you please help me understand the potential risks here?
It's not possible, as far as I know, but I'm not a macOS security expert.
And besides, "this command" ("chown") is for changing the ownership of files. That has to be one of the most dangerous commands on the entire system. Even if you could remove the password requirement for just that command, it's not much different from removing the password requirement from all system commands.
Well, would you leave your login password on a post-it note attached to your Mac? If you have your login password hardcoded in a KM macro, then anyone who can walk up to your Mac can open KM and find your sudo password. It's roughly the same problem as putting your login password on your computer for everyone to see.
For some people, that may not be a problem. But if you are doing this at work, where other people can access your Mac, that's probably a bad idea.
Removing the password for sudo means that any software that tried to execute any sudo command can do it without restrictions. As long as you never download third party apps, perhaps that's not a problem for you. Does your Mac allow remote logins? If so, that's probably another problem, as remote people would have full "root access" to your Mac. Also, some Mac commands prompt you from passwords before you harm your Mac, like deleting too many files.
There's basically a million things that could go wrong. But if you have perfect physical and perfect IT security, maybe the risks aren't too bad.
I lived through the dangerous 1990s using Windows machines without ever getting a virus. But that's because I followed a bunch of rules that reduced my risk to near zero. Most people don't like following strict rules.
I'm trying to understand the logic behind it because every day I have to do it manually.
I work with a lot of files in the audio plug-ins folder, so for every little change in that folder, my Mac asks for a password. For example, when I create a new folder, name it, add files to it, or delete files—and than doing the same in another folder—my Mac sometimes asks for the password over 10 times in just a few minutes. It's really frustrating and tiring, and this has been happening for years now. I’d love to put an end to this and enjoy managing just that specific Audio folder without a password.
So basically, if I'm already doing this manually every day, isn't it just like creating a command with permission to execute without the need to enter a password? (without giving the password to Keyboard Maestro) Am I understanding that correctly?
I was reading that thread, but I'm not an expert, so I couldn't quite grasp how to create that command as mentioned. It looks like they're discussing another command, which left me a bit confused.
Yes, that folder is owned by the system and requires system privileges to modify anything in it. This prevents malware from inserting unauthorized trusted code into your system.
You can read up here on "SIP" which is a macOS feature that prevents modifications to system programs. It's interesting.
But if security isn't important to you, and you don't have any risk of malware getting on your system, I suppose you can disable SIP. But be warned, you can get your Mac damaged very quickly and I hope you have a plan for rebuilding your macOS from scratch.
You aren't the only person who has expressed concerns with this feature. Some people think that SIP is moving macOS into a "walled garden" approach similar to iOS. It's a valid point. But you can always remove all security from macOS if you think you can be responsible for security yourself.
What application are you using that requires frequent modifications to your audio plug-ins folder? Maybe you could post a complaint on their website about how their app works.
You might also see if the plug-ins work when they're in your user's Library > Audio > Plug-Ins folder, instead of the top-level one—many apps look in the user's library first, then the system library. I have no idea if this is true for whatever app you're working with, but it might be worth trying.
What you need to do, and what that thread covers, is edit your sudoers file to allow your user account to sudo those commands without you having to type a password. You do the editing by running the visudo, see this post for how to do that.
You want to be as specific as possible to prevent unwanted commands being executed without authorisation. In this case you'd add the lines
You can do this without having to enter a password, and because it's fairly safe, I'm happy to walk you through it.
However there's no reason that you should have to be running this command so often. Running it once should suffice unless something is messing with the permissions, and I'd be tempted to figure out what that is.
Having said that…
How to do it
Type this into Terminal:
sudo visudo "/private/etc/sudoers.d/$LOGNAME"
Enter your password.
Paste these two lines in the window which appears:
I followed your instructions, and when I type Ctrl + X, then Y, then Enter, it just flashes briefly. I'm not sure if it's really saving, because when I try to quit the app, it asks if I want to terminate. Also, the shell script didn't work.
I'm getting this error message:
Action 16140667 failed: Execute a Shell Script failed with script error: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
As for your curiosity about why I have to do that, I’m not entirely sure if it’s an issue or just normal behavior. Even though I’ve already given permission to that folder using "info-apply to enclosed items"—which helps for a day or two by avoiding repeated password prompts—the folder still seems to lose permission and keeps asking for passwords. I haven’t quite figured out what triggers it, and while an Apple representative mentioned that it’s normal, it doesn’t quite feel that way to me. I’ve also noticed that some others have encountered this frustration on online forums as well.
...which will allow passwordless sudo for those commands for all admin accounts -- if you want to limit this to your account only then replace %admin with your short username on both lines
Press the esc key to exit "append" mode
Type :wq then press the Return key (: -- here comes a command; w -- write (save) the file; q -- quit visudo)
I noticed a warning after entering sudo visudo "/private/etc/sudoers.d/$LOGNAME" and password. Should I be concerned about it, or can I simply press enter and move on?
That's probably because of your previous edit attempt not being closed properly. Try the recover (R) option. I suspect you'll end up with a blank file anyway, but it's the cleanest way out.
I followed your explanation exactly. After inserting :wq at the bottom, nothing happened.
When I quit the terminal, it asked me if I wanted to cancel or terminate, and pressing enter gives me a red error. Could you help me understand what I might be doing wrong? .
