Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

user /tmp/hugo_$USER instead of /tmp/hugo_cache #7391

Closed
qnxor opened this issue Jun 15, 2020 · 10 comments · Fixed by #11082
Closed

user /tmp/hugo_$USER instead of /tmp/hugo_cache #7391

qnxor opened this issue Jun 15, 2020 · 10 comments · Fixed by #11082

Comments

@qnxor
Copy link

qnxor commented Jun 15, 2020

Using 0.72 compiled from master from 2 days ago on Ubuntu 16.04 with go 1.14. Hugo by default uses /tmp/hugo_cache to store temp files. This is a problem on a multiuser system like ours. For example, one user runs hugo server on their project folder. Another user attempt to run hugo and fails as it can't write to /tmp/hugo_cache being owned by the previous user.

I know it can be overcome by --cacheDir but it would be better to have hugo by default use /tmp/hugo_$USER instead of the hardcoded /tmp/hugo (better never to hardcode things in general anyway). Or make it a random unique dir if it's easier for cross-OS compatibility, making sure gc is doing its job.

@jmooring
Copy link
Member

You can also do something like this in ~/.bashrc:

export HUGO_CACHEDIR="hugo_cache_$USER"

@qnxor
Copy link
Author

qnxor commented Jun 16, 2020

Indeed, and that's perhaps a better workaround than using --cacheDir, but I was advocating that this is best addressed in the default implementation.

@jmooring
Copy link
Member

this is best addressed in the default implementation.

Agreed.

@bep bep added this to the v0.73 milestone Jun 16, 2020
@jmooring
Copy link
Member

jmooring commented Jun 16, 2020

Related issue: #5487

@jmooring
Copy link
Member

If you don't mind having all of your caches under source control (unless specifically ignored), you can also override the default location in config.toml. If all caches are set to :resourceDir/_gen, a hugo_cache directory in created in /tmp but remains empty. I have no idea if there are negative side effects. I am certain there is a Very Good Reason for placing the caches for getcsv, getjson, and modules in a temporary location outside of the project directory.

@qnxor
Copy link
Author

qnxor commented Jun 16, 2020

That's another useful workaround, thanks. I guess avoiding the repo is just general good practice (folks accidentally adding them to source control and then committing large sets on every commit). I found many hugo themes which do not ignore /resources (but ignore /public).

@bep
Copy link
Member

bep commented Jun 16, 2020

If you read https://gohugo.io/getting-started/configuration/#configure-file-caches

There have been some thinking in this area, see the :project placeholder.

Some of the caches should be safe to share between users/projects.

@bep bep modified the milestones: v0.73, v0.74 Jun 23, 2020
@bep bep modified the milestones: v0.74, v0.75 Jul 13, 2020
@bep bep modified the milestones: v0.75, v0.76 Sep 14, 2020
@bep bep modified the milestones: v0.76, v0.77 Oct 6, 2020
@bep bep modified the milestones: v0.77, v0.78 Oct 30, 2020
lambdanature added a commit to lambdanature/hugo that referenced this issue Apr 4, 2021
Traditional Unix uses a sticky bit on $TMPDIR to separate files and directories
from different users safely. Currently, the first user running Hugo will
therefore own $TMPDIR/hugo_cache, making it impossible for other users to use
Hugo on the same host.

If we were to tweak the directory permissions to fix this, a security issue
would remain between different users, as a malicious actor could change cached
files that are then incorporated into other users's website, or worse, could
compromise the security of the other user's account by exploiting weaknesses in
Hugo or one of its dependencies.

Any potential upsides of caching between different users are outweighed by the
security concerns, therefore completely separate Hugo's cache directory between
users seems the correct way forward.

*Fixes gohugoio#7391*.
@bep bep modified the milestones: v0.78, v0.83 Apr 23, 2021
@bep bep modified the milestones: v0.83, v0.84 May 3, 2021
@bep bep modified the milestones: v0.84, v0.85 Jun 18, 2021
@bep bep modified the milestones: v0.85, v0.86 Jul 5, 2021
@bep bep modified the milestones: v0.86, v0.87 Jul 26, 2021
@bep bep added this to the v0.103.0 milestone Aug 28, 2022
@bep bep modified the milestones: v0.103.0, v0.104.0 Sep 15, 2022
@bep bep modified the milestones: v0.104.0, v0.105.0 Sep 23, 2022
@bep bep modified the milestones: v0.105.0, v0.106.0 Oct 26, 2022
@bep bep modified the milestones: v0.106.0, v0.107.0 Nov 18, 2022
@bep bep modified the milestones: v0.107.0, v0.108.0 Dec 3, 2022
@bep bep modified the milestones: v0.108.0, v0.109.0 Dec 14, 2022
@bep bep modified the milestones: v0.109.0, v0.111.0, v0.110.0 Jan 26, 2023
@bep bep modified the milestones: v0.111.0, v0.112.0 Feb 15, 2023
@bep bep modified the milestones: v0.112.0, v0.113.0 Apr 15, 2023
Sircular added a commit to Sircular/hugo that referenced this issue Jun 10, 2023
Change the default cache directory to `$TMPDIR/hugo_cache_$USER`, so
that multi-user systems do not have caches that interfere with each
other.  The other cache-choosing logic (e.g. Netlify exceptions,
configuration options) are not affected.

Fixes gohugoio#7391
bep pushed a commit that referenced this issue Jun 12, 2023
Change the default cache directory to `$TMPDIR/hugo_cache_$USER`, so
that multi-user systems do not have caches that interfere with each
other.  The other cache-choosing logic (e.g. Netlify exceptions,
configuration options) are not affected.

Fixes #7391
@github-actions
Copy link

github-actions bot commented Jul 4, 2023

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants