awslabs/soci-snapshotter

[FEATURE] Update docs/makefile for `command not found` after `make install`

Kern-- opened this issue · 2 comments

Kern-- commented

Description

By default, make install installs SOCI binaries into /usr/local/bin. This can be overriden by setting CMD_DESTDIR when running make install.

On some distros, usr/local/bin isn't part of the default secure_path in the sudoers file and so the commands docs (e.g. Build.md), don't work:

soci-snapshotter/docs/build.md

Line 75 in 64a6ced

sudo soci --help

gives: command not found: soci.

We should update either the makefile or the docs to point people in the right direction.

Describe the solution you'd like

I think this could use some discussion, but the options that I think are available are:

  1. Use absolute paths in the docs (/usr/local/bin/soci --help)
  2. Set alias soci=sudo /usr/local/bin/soci and use non-sudo commands throughtout
  3. Add a debug note to use either some form of sudo env PATH=$PATH or edit secure path with sudo visudo
  4. Choose some other location to install by default (/bin? /usr/bin?)

Describe any alternative solutions/features you've considered

No response

Any additional context or information about the feature request

No response

pendo324 commented

I think this could use some discussion, but the options that I think are available are:

1. Add a debug note to use either some form of `sudo env PATH=$PATH`  or edit secure path with `sudo visudo`

2. Choose some other location to install by default (`/bin`? `/usr/bin`?)

I personal lean towards option 1 because it seems that convention is to put unpackaged binaries into /usr/local/bin.

The docs could also be changed to say "run sudo /usr/local/bin/soci" instead of just "run sudo soci". And then a note on how to not have to deal with that (the sudo env command, or an alias e.g. alias soci=sudo /usr/local/bin/soci, or your path propagation).

sudo path propagation (or even more permanent visudo PATH editing) has similar risks as just putting it in a "default" root PATH, if your goal is to just make it harder for a "bad" binary to be run with elevated privs.

  • 👍1
Kern-- commented

I like the idea of recommending an alias and then using non-sudo commands throughout. That would make the docs the same if we have rootless setup in the future too.