Closed honggyukim closed 3 months ago
We discussed about similar topic with other users and added it to our TODO list of DAMON, but it has deprioritized since the user told us that this is not important request. So, yes, I think this is possible, though we need to take care at the possible permission issue.
Nevertheless, may I ask you if this has important use case for you? Because this could result in complicated security issues if the implementation is imperfect, I'd like to prioritize this only if real important use cases exist.
I can't say that I have a strong use case, but I thought about this idea from kernel.perf-event-paranoid.
I feel adding sudo
for every damo record
and subsequent analysis commands hurts the general usability.
I understand that it requires to resolve some complicated security issues but I guess there might be some reference cases in other kernel parameters.
After 2024-09-05, we will[1] use damonitor repo[2] as the only main repo for GitHub. To continue discussion of this issue on the repo, I just created a new issue[3] there. Please use the new issue for followup discussions.
[1] https://lore.kernel.org/20240813232158.83903-1-sj@kernel.org [2] https://github.com/damonitor/damo [3] https://github.com/damonitor/damo/issues/2
Closing this issue in favor of the new one on the damonitor repo. Please ask me to open this again if you cannot continue the discussion from the new issue.
Hi SeongJae,
The current way of enabling damon requires root permission, but is it possible to support a way to control it from userspace by having a runtime kernel parameter?
For example, if
kernel.damon
is1
, then we could allow userspace to rundamo record
.The
kernel.damon
kernel parameter can only be changed with root permission of course.I've tested that the access permission of files in sysfs can be changed with root permission.
This might not be a realistic but I just feel that it might be much more useful if
damo record
can be executed withoutsudo
.