Add support for tty_tickets on OS X (and major breaking changes).

Add support for `tty_tickets` on OS X.
Ensure all line lengths are less than 80 characters.
Fix shell commands to use absolute path (e.g. `/bin/rm`, `/usr/bin/defaults`).
Fix `options.icns` to work with asar packages.
Fix internal method names to reduce chance of a clash with local variables.
Remove `options.onChildProcess()` (no longer possible to support).
Remove batching of password prompts on OS X.
Remove deprecated `setName()`.
Remove deprecated `touch()`.

Fixes: https://github.com/jorangreef/sudo-prompt/issues/13
This commit is contained in:
Joran Dirk Greef 2016-04-15 13:11:23 +02:00
parent 5052cb8401
commit 0b5c7d7361
2 changed files with 233 additions and 230 deletions

View file

@ -4,7 +4,7 @@ Run a non-graphical terminal command using `sudo`, prompting the user with a gra
![A sudo prompt on OS X for an app called "Ronomon"](./osx.png)
`sudo-prompt` provides a native OS dialog prompt on **OS X** and **Linux (beta)** with custom name and optional icon.
`sudo-prompt` provides a native OS dialog prompt on **OS X** and **Linux** with custom name and optional icon.
`sudo-prompt` has no external dependencies and does not require any native bindings.
@ -20,32 +20,26 @@ var sudo = require('sudo-prompt');
var options = {
name: 'Ronomon',
icns: '/path/to/icns/file', // (optional)
onChildProcess: function(childProcess) {} // (optional)
};
sudo.exec('echo hello', options, function(error, stdout, stderr) {});
```
`sudo-prompt` will use `process.title` as `options.name` if `options.name` is not provided. `options.name` must be alphanumeric only (spaces are supported) and at most 70 characters.
If `options.onChildProcess` is provided, then this callback will be called whenever the command is executed, which may be several times if a password prompt is required. For example, `options.onChildProcess` will be called when the command is first run, and if the command fails because of the lack of a sudo session, then `options.onChildProcess` will be called again the next time the command is run after the password prompt.
*Please note that `sudo.setName()` and `sudo.touch()` have been deprecated to provide a completely functional interface to `exec()`. These calls will be removed in the next major release of `sudo-prompt`.*
## Behavior
On OS X, `sudo-prompt` should behave just like the `sudo` command in the shell. If your command does not work with the `sudo` command in the shell (perhaps because it uses `>` redirection to a restricted file), then it will not work with `sudo-prompt`. However, it is still possible to use sudo-prompt to get a privileged shell, [see this closed issue for more information](https://github.com/jorangreef/sudo-prompt/issues/1).
Do not depend on any current working directory or environment variables, and use absolute paths not relative paths.
*Please note that Linux support is currently in beta and requires more testing across Linux distributions.*
On OS X, `sudo-prompt` should behave just like the `sudo` command in the shell. If your command does not work with the `sudo` command in the shell (perhaps because it uses `>` redirection to a restricted file), then it may not work with `sudo-prompt`. However, it is still possible to use sudo-prompt to get a privileged shell, [see this closed issue for more information](https://github.com/jorangreef/sudo-prompt/issues/1).
On Linux, `sudo-prompt` will use either `gksudo`, `pkexec`, or `kdesudo` to show the password prompt and run your command. Where possible, `sudo-prompt` will try and get these to mimic `sudo` as much as possible (for example by preserving environment), but your command should not rely on any environment variables or relative paths, in order to work correctly. Depending on which binary is used, and due to the limitations of some binaries, the name of your program or the command itself may be displayed to your user. Passing `options.icns` is currently not supported by `sudo-prompt` on Linux. Patches are welcome to add support for icons based on `polkit`.
On Linux, `sudo-prompt` will use either `gksudo`, `pkexec`, or `kdesudo` to show the password prompt and run your command. Where possible, `sudo-prompt` will try and get these to mimic `sudo`. Depending on which binary is used, and due to the limitations of some binaries, the name of your program or the command itself may be displayed to your user. Passing `options.icns` is currently not supported by `sudo-prompt` on Linux. Patches are welcome to add support for icons based on `polkit`.
## Non-graphical terminal commands only
Just as you should never use `sudo` to launch any graphical applications, you should never use `sudo-prompt` to launch any graphical applications. Doing so could cause files in your home directory to become owned by root. `sudo-prompt` is explicitly designed to launch non-graphical terminal commands. For more information, [read this post](http://www.psychocats.net/ubuntu/graphicalsudo).
## Concurrency
On OS X, you can issue multiple calls to `sudo.exec` concurrently, and `sudo-prompt` will batch up multiple permission requests into a single password prompt. These calls will be batched to the extent that they share the same `options.name` and `options.icns` arguments (including the actual content of `options.icns` if provided).
On systems where the user has opted to have `tty-tickets` enabled, each call to `exec()` will result in a separate password prompt. Where `tty-tickets` are disabled, subsequent calls to `exec()` (but not concurrent calls) will not require a password prompt, so long as the user's `sudo` timestamp file remains valid.
On Linux, `sudo` usually has `tty-tickets` enabled. This prevents `sudo-prompt` from batching up multiple permission requests, and will result in a separate password prompt for each call.
While `sudo-prompt` may batch up calls, you should never rely on `sudo-prompt` to execute your calls in order. For example, several calls may be waiting on a password prompt, and the next call after the password prompt may execute before any of these calls. If you need to enforce ordering of calls, then you should explicitly order your calls in your application.
You should never rely on `sudo-prompt` to execute your calls in order. If you need to enforce ordering of calls, then you should explicitly order your calls in your application. Where your commands are short-lived, you should queue your calls to `exec()` to make sure your user is not overloaded with password prompts.
## Invalidating the timestamp
You can invalidate the user's `sudo` timestamp file to force the prompt to appear by running the following command in your terminal:

443
index.js

File diff suppressed because one or more lines are too long