[Bug] Exporting Podman breaks system

[dajix350]

Please look into providing some form of safety rails to prevent the user from exporting a Podman binary from a container, as doing so breaks VSO and Apx completely (until you manually remove the exported binary)

[Maxwelldoug]

Can confirm this is an issue - we just helped a guy in the discord fix his system after he ran export podman which instantly broke the entire system.

[asyncrom]

Note: found the issue by running : apx [name of my container] export --bin podman Consequence, all the apps relying on vso and apx containers are not working anymore, Vanilla doesn't reboot, and you can't open a terminal Fix: I installed Konsole as a flatpack, and removed the export with rm ~/.local/bin/podman

[jardon]

@mirkobrombin we could implement a safeguard through apx,but i have confirmed this is something distrobox just lets you do. i replicated it in a vm, and as long as the bin is exported to a directory in the $PATH.

[mirkobrombin]

Yes I agree, we should implement a check in apx that prevents exporting binaries that are already available in the host, not only podman.

[jardon]

i could see a valid use-case for exporting other binaries that already exist on the system, but it is probably safer to block all of them

[dajix350]

Yes I agree, we should implement a check in apx that prevents exporting binaries that are already available in the host, not only podman.

There are use cases where it can be useful to export a binary that is already available on host, could you consider a flag similar to --i-know-what-i-am-doing to override the check if the user so desires?

Alternatively, this issue could be sidestepped entirely by placing ~/.local/bin after /usr/bin in $PATH

[axtloss]

Alternatively, this issue could be sidestepped entirely by placing ~/.local/bin after /usr/bin in $PATH

That's not a proper solution because apx isn't vanilla exclusive, we can't rely on the environment being set up in a specific way for every user

instead of having another flag that could break the system, binaries that are detected to be in the host should instead be exported as <binary name>.<container name>, that way there is no real possibility of an exported binary to break the host and doesn't make us add a flag that can break the system.

[mirkobrombin]

Alternatively, this issue could be sidestepped entirely by placing ~/.local/bin after /usr/bin in $PATH

That's not a proper solution because apx isn't vanilla exclusive, we can't rely on the environment being set up in a specific way for every user

instead of having another flag that could break the system, binaries that are detected to be in the host should instead be exported as <binary name>.<container name>, that way there is no real possibility of an exported binary to break the host and doesn't make us add a flag that can break the system.

That could introduce a lot of misunderstanding in my opinion. If some binaries are exported as they are and some with a different name... it is a problem. Also, if the user export the binary and then install the same in the host, the problem will stay. And this is the same even with what I proposed. I think binaries should ALWAYS be exported with the apx subsystem name as a suffix (suffix so that you can easily take advantage of autocomplete when you press for example "ca" then Tab and it will show you "cat".

Must be noted, this will break a possible workflow (that I use), so having git installed in my dev subsystem and let other programs, on host or other subsystems, detect and use it. Not sure if even this is the correct solution. Maybe, we can always export binaries as they are just not in the .local/bin path but in a different one, and make a new feature to allow the user to give access to those binaries to a different subsystem. but that could be a bit out of scope, idk, looks a lot like cpak lol.

[axtloss]

Not sure if even this is the correct solution. Maybe, we can always export binaries as they are just not in the .local/bin path but in a different one, and make a new feature to allow the user to give access to those binaries to a different subsystem. but that could be a bit out of scope, idk, looks a lot like cpak lol.

this seems like a completely different feature tbh, nice to have but out of scope here

That could introduce a lot of misunderstanding in my opinion. If some binaries are exported as they are and some with a different name... it is a problem. Also, if the user export the binary and then install the same in the host, the problem will stay.

That's true, apx should always export with a suffix, the user can still symlink the right binary name if they need it configured that way

[jardon]

i dont think the main issue here is preventing a user from breaking their system by some manual, advanced method. users will always be able to misuse tools and hack their way into oblivion.

the immediate need is a simple safeguard to prevent users from unknowingly using apx to cripple their system. anything past that should really be addressed somewhere else with a more design/engineering discussion.

i think forcing the export to make a binary with the name <binary>.<subsystem> would be sufficient to avoid at least 90% of what the users are currently complaining about.

[axtloss]

the immediate need is a simple safeguard to prevent users from unknowingly using apx to cripple their system. anything past that should really be addressed somewhere else with a more design/engineering discussion.

Not really, it's a lot better to just have the right solution implemented immediately than have some quick patch as a workaround, this isn't a huge security vulnerability or something, there is no need to rush a fix

[jardon]

I disagree. Security vulnerabilities are not the only reason to push out quick fixes. Having multiple users report inoperable systems is plenty of a reason to try to push out a quicker fix. But I won't argue with you. It's not up to me.

@mirkobrombin I'll defer to you.