Create not erasable toolbox

Ask Fedora
,
1

Hi,

I checked out into the forum but it seems there are no topics related to that.

In fedora silverblue 41, I often use toolboxes for creating development environments (for trying new features, code development,…).

Is it possible to control toolbox permissions, so that we can avoid erasing a toolbox by mistake?

The final result should be receiving an error in case the user tries to delete the toolbox(or the underlying container using podman).

2

hi there.

Afaik, these user containers are stored in ~/.local/share/containers/storage/volumes/. They have random values (maybe a machine finds them very understandable)

So you could try and find the correct one and make it non-erasable, in theory by chowning it to another user, and granting your user all permissions apart from delete.

But there is an issue: normally you use containers as a tool, you download and use it, and when updating, you just replace it. This is not done with toolbx/distrobox, there you use the container as an environment and make changes inside it.

BUT Fedoras dnf updater does not allow upgrading the distro within the container. At least I havent found out how to do so, yet. So the recommended way is to scrap your changes and remove and re-“deploy” the container to update it.

This is quite bad, distrobox allows using a compose file to make this less painful.

So it would not make perfect sense to protect it, as

  • you may change it, until it becomes a “ship of theseus”
  • This will include deleting files, so it could not even be possible to prevent deletion, as it would apply to all files in it
  • it will need to be replaced every year

Containers are not great UX-wise yet ;D

3

hi @boredsquirrel,

thank you for your answer.

What I was looking for was a way to “lock” the toolbox from accidental deletion(so that I could manually unlock it just before swapping to some “upgraded” version of the image). And this because my toolbox is a dev one(and it’s very likely to play with containers and scripts).

Btw, I tried to get the storage directories relating to toolbox containers. Using the podman inspect command over the toolbox, I found following folders:

~/.local/share/containers/storage/overlay-containers/...
~/.local/share/containers/storage/overlay/...
/run/user/1000/containers/overlay-containers/...

After chowning to root only the directories relating to my toolbox, I tested the change by trying to remove it. I received an error reporting I could not delete the toolbox(good), but after launching toolbox list , the toolbox was not there (it had been removed anyway, not so good :sweat_smile:)

1 Like
4

Yes chowning stuff is not as easy. I am pretty certain that the owner can always delete files. Might try to remove the delete permission from it

5

I think that you’re looking for things like called devcontainers in the vscode way
I would suggest you to build images with your tools and run them with your app files in bind mount volumes

6

You may be better off just making a backup after you get it working …

2 Likes
7

Yes, kind of. The idea was to “isolate” everything required for dev into a toolbox, thus avoiding to install it into the main OS.

Eventually I think I’ll go for the backup/restore (as proposed by @grumpey ) or I’ll create a script in order to quickly rebuild the toolbox when required.

Thanks

8

The script you’re talking about seems to be a Containerfile/Dockerfile …
I don’t know projects you’re working on but it seems that you try to workaround things that containers are made for

9

I was just looking for a way to build a flexible and robust dev env on silverblue(considering that installing apps/packages using rpm-ostree is possible but not recommanded). I was evaluating toolboxes as they seemed to me the suggested tools for that.