0

I've setup restricted shell(s) on an Arch-based system by creating /usr/local/bin/rzsh and /usr/local/bin/rbash:

these scripts cd into /home/$USER and then invoke zsh -r and bash -r respectively, but I would like users in the restricted shells to be able to cd into directories the user(s) explicitly own (such as sub-directories of their home) but not necessarily everything they have read access to.

  • The context is a user that runs https://code.visualstudio.com/docs/remote/vscode-server - clients have terminal access and must be able to move between repositories, and execute some scripts that act upon repositories

  • However, I do not want users to have access to cd into or read files in system directories

Is this possible with a restricted shell, and if not, can you recommend an approach to achieve a similar level of restriction?

Improve this question

2 Answers 2

Reset to default
1

You might want to containerize the vscode-server instance. That way, the "system directories" outside the legitimate access area within the container should be minimized and contain basically just the things needed to run the vscode-server and nothing more.

Note that the Common Questions chapter on the vscode-server page says:

Is the VS Code Server designed for multiple users to access the same remote instance?

No, an instance of the server is designed to be accessed by a single user.

This suggests you may be trying to use the vscode-server in a way/for a purpose it's explicitly not designed for.

This is likely to lead to grief as the vscode-server gets updates over time: either you take the workload of maintaining an increasing number of workarounds to keep it doing what you want despite the new versions gaining more and more of what you will see as misfeatures; or you stick with an old version you can make work the way you want, even if it may have unfixed bugs and miss new features you might actually want.

Improve this answer
1

You cannot use cd inside a restricted shell except in the shell initialisation files (such as ~/.bash_profile and ~/.bashrc).

Note that neither these files nor the user's home directory itself should be writable by the user, as otherwise they could simply edit or replace the initialisation files with code of their choice.

Improve this answer
3
  • Interesting, can you add any details on why the home directory should not be user writable? My original intention was to restrict read access to any system directories, is there perhaps a better way to do this? I'm adding some context to the question. Commented Aug 14, 2024 at 22:26
  • 1
    If the user has write access to their home directory, and you allow them to run mv (or equivalent) and an editor, they can replace their “.” files (e.g., .bash_profile and .bashrc). Commented Aug 14, 2024 at 23:22
  • @G-ManSays'ReinstateMonica' thank you. I've extended the answer to make this clear Commented Aug 15, 2024 at 9:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.