docs: Add guide on how to give Remoteproc Runtime permission to a user #6
docs: Add guide on how to give Remoteproc Runtime permission to a user #6yejseo01 wants to merge 16 commits into
Conversation
Remoteproc Runtime uses Remoteproc, which usually requires root permissions to write to its filesystem. To ensure that Remoteproc Runtime has root access, the container engines that spawn containers with Remoteproc Runtime should be run with root access. Signed-off-by: Yejin Seo <yejseo01@arm.com>
There was a problem hiding this comment.
Pull Request Overview
This PR adds documentation to clarify that root permissions are required when using Remoteproc Runtime with container engines. The addition explains that remoteproc devices require root access to write to filesystem interfaces, and provides guidance on running container engines with appropriate privileges.
Key Changes:
- Added a paragraph explaining the necessity of root permissions for remoteproc device access
- Included guidance on running container engines (Docker daemon, K3S, Podman) with root privileges
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: yejseo01 <yejseo01@arm.com>
Signed-off-by: Yejin Seo <yejseo01@arm.com>
th3james
left a comment
There was a problem hiding this comment.
Very cool that we got this working. Some suggested readability tweaks.
| @@ -0,0 +1,51 @@ | |||
| # Permission setting for non-root users' usage of Remoteproc Runtime | |||
|
|
|||
| For non-root users to use Remoteproc Runtime, the remoteproc driver and the container engine must be accessible for this user. | |||
There was a problem hiding this comment.
| For non-root users to use Remoteproc Runtime, the remoteproc driver and the container engine must be accessible for this user. | |
| Remoteproc Runtime processes must run with privilege to access the remoteproc sysfs entries. Remoteproc Runtime is typically invoked by the container engine, not the user directly, so the container engine process is actually the process which needs the relevant permissions. |
There was a problem hiding this comment.
I haven't checked the user id inside the container engine, but I didn't need to add the container engine's user directly to the remoteproc authorized group to make it work. The suspicion I have is the container spawned in either a root or the user that spawned
| # start/stop | ||
| echo start | tee /sys/class/remoteproc/remoteproc0/state | ||
| echo stop | tee /sys/class/remoteproc/remoteproc0/state | ||
| ``` |
There was a problem hiding this comment.
Do we need a last step here noting that the container engine needs to be added to this new group?
There was a problem hiding this comment.
I didn't need to add the container engine to the new group to make this work without root. What would the user be in a spawned container??
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Co-authored-by: James Cox-Morton <Th3james@fastmail.fm> Signed-off-by: yejseo01 <yejseo01@arm.com>
Remoteproc Runtime uses Remoteproc, which usually requires root permissions to write to its filesystem.
There are some extra configuration work that needs to be done to enable a non-root user to be able to use Remoteproc Runtime, and this change adds the document for it.
Changes
Checklist