starred/ArchiveBox

Fork 0

mirror of https://github.com/ArchiveBox/ArchiveBox.git synced 2026-04-25 17:16:00 +03:00

data fails, causing chown of contents of dir the script is run from #3960

New issue

Closed

opened 2026-03-15 01:07:28 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 01:07:28 +03:00

Owner

Originally created by @1over137 on GitHub (Nov 3, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1584

Originally assigned to: @pirate on GitHub.

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
github.com/ArchiveBox/ArchiveBox@1148cadd7a/bin/setup.sh (L53)
This fails, but the script continues.
github.com/ArchiveBox/ArchiveBox@1148cadd7a/bin/setup.sh (L54)
This fails, but the script keeps running. We are still in the user's home!
github.com/ArchiveBox/ArchiveBox@1148cadd7a/bin/setup.sh (L58)
This fails, but the script keeps running. We are still in the user's home!
github.com/ArchiveBox/ArchiveBox@1148cadd7a/bin/setup.sh (L59)
This fails because it will refuse to init if folder is non-empty. We are still in the user's home!
github.com/ArchiveBox/ArchiveBox@1148cadd7a/bin/setup.sh (L62)
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.

Originally created by @1over137 on GitHub (Nov 3, 2024). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1584 Originally assigned to: @pirate on GitHub. 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 https://github.com/ArchiveBox/ArchiveBox/blob/1148cadd7aa6ea902668b1a527aa9cba3060c90e/bin/setup.sh#L53 This fails, but the script continues. https://github.com/ArchiveBox/ArchiveBox/blob/1148cadd7aa6ea902668b1a527aa9cba3060c90e/bin/setup.sh#L54 This fails, but the script keeps running. **We are still in the user's home!** https://github.com/ArchiveBox/ArchiveBox/blob/1148cadd7aa6ea902668b1a527aa9cba3060c90e/bin/setup.sh#L58 This fails, but the script keeps running. **We are still in the user's home!** https://github.com/ArchiveBox/ArchiveBox/blob/1148cadd7aa6ea902668b1a527aa9cba3060c90e/bin/setup.sh#L59 This fails because it will refuse to init if folder is non-empty. **We are still in the user's home!** https://github.com/ArchiveBox/ArchiveBox/blob/1148cadd7aa6ea902668b1a527aa9cba3060c90e/bin/setup.sh#L62 **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.

kerem

2026-03-15 01:07:28 +03:00

closed this issue
added the
status: done

why: security

size: easy
labels

kerem commented

2026-03-15 01:07:45 +03:00

Author

Owner

@pirate commented on GitHub (Nov 4, 2024):

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 commented on GitHub (Nov 4, 2024): `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](https://docs.sweeting.me/s/against-curl-sh) and have been wanting to remove it for years. With the new versions you can just do: ```bash 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.

kerem commented

2026-03-15 01:07:50 +03:00

Author

Owner

@pirate commented on GitHub (Nov 4, 2024):

I've updated setup.sh in the meantime: github.com/ArchiveBox/ArchiveBox@fd89de5b91

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:
github.com/ArchiveBox/ArchiveBox@c1fd2cfa42/archivebox/main.py (L308)

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.

@pirate commented on GitHub (Nov 4, 2024): I've updated `setup.sh` in the meantime: https://github.com/ArchiveBox/ArchiveBox/commit/fd89de5b912e2d5c845e6e406e0c364c754fa1f7 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: https://github.com/ArchiveBox/ArchiveBox/blob/c1fd2cfa42f3c81d4c5a2a3c95733f4804fda938/archivebox/main.py#L308 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 `chown`ing.

kerem commented

2026-03-15 01:07:55 +03:00

Author

Owner

@1over137 commented on GitHub (Nov 4, 2024):

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.

@1over137 commented on GitHub (Nov 4, 2024): 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.

kerem commented

2026-03-15 01:08:00 +03:00

Author

Owner

@pirate commented on GitHub (Nov 4, 2024):

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

./logs
./crontabs
./archive

@pirate commented on GitHub (Nov 4, 2024): There just a couple others to check for depending on how far it got: - `./logs` - `./crontabs` - `./archive`

kerem commented

2026-03-15 01:08:05 +03:00

Author

Owner

@1over137 commented on GitHub (Nov 4, 2024):

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

@1over137 commented on GitHub (Nov 4, 2024): Only logs was created. Also not everything was chown'd, so most likely it got killed in the middle of that `find` command

kerem commented

2026-03-15 01:08:10 +03:00

Author

Owner

@pirate commented on GitHub (Nov 4, 2024):

I've added an extra step that prevents this at the docker level even if a user doesn't use setup.sh: github.com/ArchiveBox/ArchiveBox@99ed97836f

@pirate commented on GitHub (Nov 4, 2024): I've added an extra step that prevents this at the docker level even if a user doesn't use `setup.sh`: https://github.com/ArchiveBox/ArchiveBox/commit/99ed97836ff42565a30dcb7ecbf3432778d19d15

kerem commented

2026-03-15 01:08:15 +03:00

Author

Owner

@1over137 commented on GitHub (Nov 4, 2024):

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

@1over137 commented on GitHub (Nov 4, 2024): I would check for something like .bashrc/.zshrc. Many servers do not have Documents and some do not have a .config

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ArchiveBox#3960

No description provided.

Rows
Columns