cockpit-ws bastion/unprivilleged forced ssh-agent

[engelant]

cockpit/containers/ws/label-run

Line 45 in f985ad0

eval $(ssh-agent)

My issue being, that ssh-agent is started unconditionally.

Can anybody spot any harm in wrapping this in a start if unset condition like so:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent)"
fi

This would enable me to provide my own SSH_AUTH_SOCK without breaking behavior.

[martinpitt]

This seems fine to me -- cautiously. You really need to know what you are doing, i.e. do this together with configuring the container for using a private key. You are crossing a security boundary here, i. e. give the container access to your user session. We don't know of any way to exploit it, and the flatpak essentially does the same -- but that doesn't expose cockpit's web server to the network.

[engelant]

By harm I really just ment for other users in terms of compatability.
Right now for testing i just used a Containerfile to sed out the line, and it works as intended.
Especially under linux I am against hiding potentially dangerous settings, but only if "we don't break userspace".

Therefor my main concern is wether this could break any potentiall existion application.
As it only affects the container label-run and an admin would have to explicitly have set SSH_AUTH_SOCK for an unprivileged environment for the behaviour to change.

[martinpitt]

No, I can't imagine breaking any existing realistic setup. Setting $SSH_AUTH_SOCKET in the container never worked and was never documented.