Grant only write access to another shell user's (sub)directory

HelenaGwyn

Following https://docs.opalstack.com/topic-guides/tips/#howto-grant-access-to-a-directory I granted all my shell users access to a backup folder within a dedicated backup shell user that will transfer them daily to an offsite box-account. Every shell user writes their backups into this folder. I don't want to configure this box-connection every time I create a new shell user for a new client or application.

At this moment, every shell user can read, write and execute in this folder. Can rights be granted in such a way that the shell user can only write its own backups without the right to read files, do a directory listing and execute?

sean

HelenaGwyn Directory permissions work like this:

Read: lets you list the contents of the directory
Write: lets you create/modify files in the directory
Execute: lets you traverse into a directory

For write-only access you need to be able to traverse into the directory and to create/modify files in the directory, so you'll need write and execute permission.

The command to set write+execute for other users on a directory is:

chmod o+wx /home/you/path/to/directory

However, if you do this it will give every shell user on the server write access to that directory, including shell users which belong to other accounts. If you're on shared hosting then you almost certainly don't want to to do that, so you'll need to set the permissions for each individual user via the setfacl command.

The setfacl command for that is:

setfacl -m u:shell_user_name:-wx /home/you/path/to/directory

You can avoid repeating this step manually for every new shell user by using our API to automate whatever tasks you're running. For example, you might take the following steps for each new project:

Add the site domains
Create a shell user
Create a Wordpress application
Create a site to serve the app
Configure your backup permissions

Instead of doing all of these steps manually, you can create an API script that prompts you for the domains, shell user name, and app name and then performs the tasks for you.

HelenaGwyn

Thank you!

I revised my backup strategy. I now create a folder with the right permissions for each new shelluser and link to that one.

mkdir $HOME/backups/<shelluser>
setfacl -m u:<shelluser>:--x $HOME/backups
setfacl -m u:<shelluser>:rwx $HOME/backups/<shelluser>
setfacl -R -m d:u:<shelluser>:rwx $HOME/backups/<shelluser>
setfacl -R -m d:u:backups:rwx $HOME/backups/<shelluser>
chmod g+s $HOME/backups/<shelluser>

The API is on my todo-list 🙂. Looking forward to some examples in the documentation.

HelenaGwyn

If I use the API in a bash-script run by my backup-shelluser, I suppose the Wordpress application created for a new shelluser uses the basic installer provided by Opalstack?

Is it possible to run my own custom wordpress-install-script instead to create the application? I have a few extra plugins and settings I want to do with wp cli and finish with creating backupscripts for the app.

sean

HelenaGwyn When our dashboard creates a Wordpress app, it makes an API call to app/create to create a new Nginx/PHP-FPM app (type = "NPF") with https://raw.githubusercontent.com/opalstack/installers/master/core/wordpress/install.sh as the installer_url parameter.

If you want to use some other script, then use the URL to that script instead.

You'll need to upload your script somewhere first, so that the dashboard server can fetch it when it goes to create the app. You can create a static app and site via our dashboard for that purpose, or use any static hosting service that you prefer.

Note that our WP install script is what installs wp-cli into your home directory, so if you plan to run your installer via a shell user that doesn't already have wp-cli then you'll need to include the commands to install that as well.

HelenaGwyn

sean Thanks, going to build my script with that as a starting point.

I see it gets these parameters:

# i is for UUID, t is for user token, n is for app name
while getopts i:n: option
do
case "${option}"
in
i) UUID=${OPTARG};;
n) APPNAME=$OPTARG;;
esac
done

I pass them, and possibly other parameters, to the script within the json-property?:

[
{
"name": "string",
"osuser": "5e103e0d-b091-45f6-9e5b-a15d70531804",
"type": "NPF",
"installer_url": "http://example.com",
"json": {
"i": "UUID",
"n": "appname"
}
}
]

sean

HelenaGwyn The app UUID doesn't exist until after the app is created, so it's not used as an input for app/create.

Here's a complete example payload for app/create:

[
  {
    "name": "name_of_new_app",
    "osuser": "UUID_OF_SHELL_USER",
    "type": "NPF",
    "installer_url": "http://example.com/your_install_script.sh",
    "json": {
      "php_version": 80,
      "fpm_max_requests": 25,
      "fpm_max_children": 5
    }
  }
]

You can use curl to make the call from bash:

curl -s -X POST -H "Content-Type:application/json" -H "Authorization: Token YOUR_TOKEN" -d '[{"name": "name_of_new_app","osuser": "UUID_OF_SHELL_USER","type": "NPF","installer_url": "http://example.com/your_install_script.sh","json": {"php_version": 80,"fpm_max_requests": 25,"fpm_max_children": 5}}]'

Note that you can write your installer script in whatever language you want, there's no requirement that you use bash. The only requirements are that the language has the capability to make HTTP requests, parse json, and do whatever other tasks you need the script to do.

HelenaGwyn

sean Hi again, just wondering, does the API support installer_urls with authentication?

HelenaGwyn

Can I pass custom parameters to the installscript?

sean

HelenaGwyn No, when the dashboard runs app/create it does the following:

Creates the basic empty Nginx/PHP-FPM app.
Downloads your install script into ~/.ossrc/NNNN-NNNN-NNNN-NNNN-NNNN (the filename is the returned UUID of the app from step 1).

Calls your install script with 2 parameters, the app name (the 'n' parameter) and app UUID (the 'i' parameter), like so:

cd ~/apps/name_of_app
~/.ossrc/XXXXXXXX -n my_new_app -i NNNN-NNNN-NNNN-NNNN-NNNN

You can't change the parameters that get passed to the script.

HelenaGwyn

sean

Ok, thank you for clearing that up.

I thought about passing along f.e. which plugins to install, what mailaddress to use, etc. .
Some things will have to be done manually then or figure out a workaround creating and reading out a temporary configuration file.