Bug: setup.sh continues even if creating ~/archivebox/data fails, causing chown of contents of dir the script is run from

[1over137]

Not a security vulnerability (at least in a way I can think of)
I assume I'm just very unlucky today and I triggered a somewhat dangerous bug in https://github.com/ArchiveBox/ArchiveBox/blob/dev/bin/setup.sh.

Preconditions

• No docker-compose binary (N.B. I don't think this binary is shipped anymore, so that detection will never pass, you might want to consider changing this)
• Having already previously manually ran a command like this, which initializes a archivebox data folder:

docker run -v ~/archivebox:/data -it -d -p 8000:8000 --name=archivebox archivebox/archivebox:latest init --setup

Notice that this chown's ~/archivebox, resulting in permission denied if you try to cd in it. This sets the stage for the bug.

Bug

Going through setup.sh, starting at line 52

ArchiveBox/bin/setup.sh

Line 53 in 1148cad

mkdir -p ~/archivebox/data

This fails, but the script continues.

ArchiveBox/bin/setup.sh

Line 54 in 1148cad

cd ~/archivebox

This fails, but the script keeps running. We are still in the user's home!

ArchiveBox/bin/setup.sh

Line 58 in 1148cad

cd ./data

This fails, but the script keeps running. We are still in the user's home!

ArchiveBox/bin/setup.sh

Line 59 in 1148cad

docker run -v "$PWD":/data -it --rm archivebox/archivebox:latest init --setup

This fails because it will refuse to init if folder is non-empty. We are still in the user's home!

ArchiveBox/bin/setup.sh

Line 62 in 1148cad

docker run -v "$PWD":/data -it -d -p 8000:8000 --name=archivebox archivebox/archivebox:latest

This runs in the user's home. Many files get chown'd to the user ID 911, including the user's home directory itself. This renders the user unable to access his own files, and requires root to recover.

Some general advice

In general, any commands that can possibly fail in a shell script, when it fails unexpectedly (like the first mkdir -p command) should terminate the entire script. You might want to include a die function and use mkdir -p ~/archivebox/data || die, then it would have killed the script instead of letting it keep going.

Reference: https://stackoverflow.com/questions/7868818/in-bash-is-there-an-equivalent-of-die-error-msg

Questions

What does the program do after that command runs besides chown'ing the files? I'm considering recovering from a backup in case it changed any files.

[pirate]

setup.sh is completely deprecated as of v0.8.6rc0. I'm about to remove it entirely as an install option because I really dont like curl | sh as an install method and have been wanting to remove it for years.

With the new versions you can just do:

pip install archivebox==0.8.5rc50

archivebox install

archivebox install starts with an init, so it should die properly before attempting to chown anything.

Also note the new docker container versions for v0.8.5 and above will autodetect the existing ownership of any passed data dir, so it shouldn't force 911 anymore if you pass it a dir that you've already created.

[pirate]

I've updated setup.sh in the meantime: fd89de5

To see what else the Docker container does on startup to the data dir you can read this script:
https://github.com/ArchiveBox/ArchiveBox/blob/dev/bin/docker_entrypoint.sh

And the init source code here:

ArchiveBox/archivebox/main.py

Line 308 in c1fd2cf

def init(force: bool=False, quick: bool=False, setup: bool=False, out_dir: Path=OUTPUT_DIR) -> None:

It creates a chowns a few subdirectories, but nothing dangerous that should warrant having to restore your entire ~ from a backup. There are no deletions or edits of files other than ArchiveBox.conf, only creation and chowning.

[1over137]

That's what I figured. The only observable effect seems to be the creation of a logs directory under ~. The chown'ing quickly killed my compositor and the shell which the command runs on, so it probably didn't get to the rest of script.

[pirate]

There just a couple others to check for depending on how far it got:

• ./logs
• ./crontabs
• ./archive

[1over137]

Only logs was created. Also not everything was chown'd, so most likely it got killed in the middle of that find command

[pirate]

I've added an extra step that prevents this at the docker level even if a user doesn't use setup.sh: 99ed978

[1over137]

I would check for something like .bashrc/.zshrc. Many servers do not have Documents and some do not have a .config