You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The IMP is executed directly by the instance and therefore inherits the environment of the executing broker, modulo any environment variables stripped by the kernel if the IMP is setuid.
This is ok for the IMP since we are careful to run minimal code under privilege, and if installed setuid the kernel will clean LD_LIBRARY_PATH and LD_PRELOAD for us.
However, we may want to do a similar service for the job shell and start it with a clean environment, if possible. We may want to copy sudoers and have a whitelist/blacklist for environment variables in the config.
It may be impossible to fully protect the job shell environment. E.g. we'll need to allow LD_LIBRARY_PATH to be passed through if the version of Flux was side installed, and if so then the instance could cause the job shell running as a different user to execute arbitrary code. Since there is implicit "trust" between a guest and an instance owner, maybe this all a bit too paranoid.
The text was updated successfully, but these errors were encountered:
The IMP is executed directly by the instance and therefore inherits the environment of the executing broker, modulo any environment variables stripped by the kernel if the IMP is setuid.
This is ok for the IMP since we are careful to run minimal code under privilege, and if installed setuid the kernel will clean
LD_LIBRARY_PATH
andLD_PRELOAD
for us.However, we may want to do a similar service for the job shell and start it with a clean environment, if possible. We may want to copy
sudoers
and have a whitelist/blacklist for environment variables in the config.It may be impossible to fully protect the job shell environment. E.g. we'll need to allow LD_LIBRARY_PATH to be passed through if the version of Flux was side installed, and if so then the instance could cause the job shell running as a different user to execute arbitrary code. Since there is implicit "trust" between a guest and an instance owner, maybe this all a bit too paranoid.
The text was updated successfully, but these errors were encountered: