chipjarred
commented
1 year ago Note: In this comment when I refer to path I am confusing it with command. path is set by the main app with the intention of its being used as the argument to /bin/ls. The discussion has moved on quite a bit since I posted this, so instead of correcting the text below, I just want to provide that context for anyone coming to this discussion at a later time.
I assume that you're referring to the call to runTask(command:arguments:completion:) in Helper.runCommandLs(withPath:completion:). First of all, you shouldn't need sudo since the point of the Helper is to authenticate that you can run the task. I'm guessing that you are indeed executing sudo which is silently waiting on a password (or maybe terminating) because it's not running on a tty. Think of a privileged helper tool as being a substitute for sudo.
Instead you'd provide the path to the thing that would come after sudo on the command line; however, you want to run a shell script, which is questionable for security, but you can do it. Installer packages for example, run shell scripts and sometimes need to run them with elevated privileges.
path has to refer to something that can be run by the link-loader, which on macOS means it has to be a Mach-O binary executable. It can't be a script or byte code.
So how do you run a shell script? While the script is not a Mach-O executable, the shell itself is. So you set path to the shell, for example, path = "/bin/zsh" for z-shell. Then you pass the name of the script as the first element of arguments. To avoid launching unnecessary sub-shells use the correct shell for the script, so if it starts with #!/bin/csh for example, use /bin/csh instead of /bin/zsh for path. If you use the wrong shell, it's not a big problem. It just means the shell you did specify will have to launch the one that the script wants in order to run the script.
If the script takes arguments, as it does for your example, don't pass them in as a single string. Each argument should be its own element in arguments. For your example, arguments = ["pmset", "disable", "sleep", "1"].
For a python script you could run it through the shell like that, calling python as the first of the arguments and the script as the second, but it's better to call the python interpreter directly: path = "/usr/bin/python", then python script becomes the first element in arguments.
This same pattern applies to pretty much any kind of script, like ruby, perl, awk, etc...
I would only run them via a shell if for some reason I needed some shell facility to resolve the arguments, like expanding wildcards (eg, if an argument needed to be something like "*.txt"). Obviously for a shell script you need the shell.
One other tip... remember the user's PATH environment variable may not be set the same as yours. If their PATH doesn't include the directory where the named script lives, the shell won't find the script. Instead, use the full path to the script as the first element of arguments.
If you can, do the work directly in the helper tool.
The project is a sort of template you're supposed to modify, so as one more piece of advice, if you don't need a script to do what you want, then don't use a script. A shell script is just a text file and if a malicious actor gets access to it, when you execute it with elevated privileges, you're running malicious code with privileges that can do some real damage or leak personal information. Instead, it's much more secure, if you can do what you want to do programmatically in Swift (or Objective-C, or C), and just call that code directly in your helper tool. In your helper tool you have access to pretty much the entire AppKit API, as well as to all the BSD/POSIX functions. In principle, anything you can do in a shell script you could do directly in Swift code.
Your example might not need a helper tool
If all you want to do is to disable sleep while you perform some task, you may not even need to use a helper tool at all. I don't think this code needs elevated privileges, so it should work directly in your app:
let activity = ProcessInfo.processInfo.beginActivity(
options: [.idleDisplaySleepDisabled, .idleSystemSleepDisabled],
reason: "I'm busy working! No time for sleep!"
)
someConcurrentDispatchQueue.async {
doSomeLongRunningWork()
ProcessInfo.processInfo.endActivity(activity)
}Of course, that only works if you're just trying to prevent the system from going to sleep while your program performs some long running task. If instead the goal is to change the system settings so they persist after your app terminates, then yeah, you'll need the helper tool.
jeff-h
mansidak
I've been studying this code and noticed that there is a 'path' parameter and an 'argument' parameter. Like I can give a command of '/bin/sudo' and it works but we know that it doesn't really do anything. How can I actually run a 'sudo' command in this? Let's say something like 'sudo pmset disable sleep 1'. Unless I'm misunderstanding something, I can't figure out a way to actually run a shell script.