Dockerfile: put some XDG dirs under /tmp - #16304
Conversation
Signed-off-by: William Woodruff <william@trailofbits.com>
di
left a comment
There was a problem hiding this comment.
This seems fine to me but will let @ewdurbin and/or @miketheman weigh in as well.
|
that all checks out. would it make sense to have cabotage do this in its wrapper layer, since that is where the user clobbering happens? also then other stuff running there benefits. if this goes well, adding to https://github.com/cabotage/cabotage-app/blob/e50890c43353e6a21361d8abf1fd4f8e0d7e46e8/cabotage/utils/release_build_context.py#L3-L11 seems like a good move. |
I think so, although I'm curious about testing this -- I think it'd be good to have a "backstop" type test to ensure these paths are functional, and I'm not sure if that's easier to do in Cabotage or in Warehouse 😅 |
|
Yeah, looks like this needs to happen in Cabotage -- the |
Opening this up for consideration/feedback, not sure if this is the best approach yet 🙂
Background context:
sigstore-pythoncurrently usesplatformdirsto place it somewhere sensible under the user's local data/cache dirsuid=nobodywith$HOME=/nonexistent, meaning that the XDG dirs don't exist.gracefully addresseshacks around the above by creating two new directories under/tmpand using them as Warehouse's XDG dirs.From a functionality/correctness perspective, this should have no impact on Warehouse: nothing else appears to use the XDG dirs and, if anything in the future does, it should be redirected to these new ones.
From a security perspective: this puts the XDG dirs in a "global" temporary directory within the container. However (AFAICT), Warehouse intentionally runs as
nobodywith a rootless configuration to mitigate this kind of minor risk.CC @di