| Wazuh version |
Component |
Install type |
Install method |
Platform |
| 3.9.x-x |
Framework |
Manager |
Any |
Any |
Description
When trying to unset a high volume of agents from a group, a timeout arises. After that error, any other operations involving agents and groups fail with a 1005 error and the message Operation not permitted. The only way to fix it seems to be running the agent operation through command line using the agent_groups utility with root privileges.
Cause
The error is due to a conflict between remoted and the Wazuh API. According to the following code, the framework tries to create the multigroup folder manually:
|
@staticmethod |
|
def create_multi_group(group_id): |
|
""" |
|
Creates a multi group. |
|
:param group_id: Group ID. |
|
:return: Confirmation message. |
|
""" |
|
|
|
if ',' not in group_id: |
|
# if there's not , in the group_id, then it isn't a multigroup and therefore the function does nothing |
|
return |
|
|
|
# Create group in /var/multigroups |
|
try: |
|
folder = hashlib.sha256(group_id.encode()).hexdigest()[:8] |
|
multi_group_path = "{0}/{1}".format(common.multi_groups_path, folder) |
|
mkdir_with_mode(multi_group_path) |
|
chown(multi_group_path, common.ossec_uid, common.ossec_gid) |
|
chmod(multi_group_path, 0o770) |
|
msg = "Group '{0}' created.".format(group_id) |
|
return msg |
|
except OSError as e: |
|
if e.errno != errno.EEXIST: |
|
raise WazuhException(1005, str(e)) |
|
|
|
return msg |
Since the API usually runs as
ossec, it fails the attempt to execute the
chown or
chmod, showing an
Operation not permitted error because those files belongs to
ossecr.
It is important to note that
remoted uses the
agent-groups folder to recreate every 15 seconds the proper multigroup folder hierarchy, so there is a race condition.
Proposed fix
The quickest way to fix this is removing the manual creation of multigroups, maintaining only the edition of agent-groups. This way, remoted would be the only one in charge of handling those folders.
However, this is not the optimal solution. To reach the best solution, a daemon should be responsible for managing the groups and multigroups folder hierarchy, accepting a request via socket (or HTTP REST API even better).
This idea should be extended to any other functions handling folder or files manually via framework and delegate these tasks to an unique Wazuh daemon.
Description
When trying to unset a high volume of agents from a group, a timeout arises. After that error, any other operations involving agents and groups fail with a 1005 error and the message
Operation not permitted. The only way to fix it seems to be running the agent operation through command line using theagent_groupsutility with root privileges.Cause
The error is due to a conflict between
remotedand the Wazuh API. According to the following code, the framework tries to create the multigroup folder manually:wazuh/framework/wazuh/agent.py
Lines 1476 to 1501 in b3dc8c2
Since the API usually runs as
ossec, it fails the attempt to execute thechownorchmod, showing anOperation not permittederror because those files belongs toossecr.It is important to note that
remoteduses theagent-groupsfolder to recreate every 15 seconds the proper multigroup folder hierarchy, so there is a race condition.Proposed fix
The quickest way to fix this is removing the manual creation of multigroups, maintaining only the edition of
agent-groups. This way,remotedwould be the only one in charge of handling those folders.However, this is not the optimal solution. To reach the best solution, a daemon should be responsible for managing the groups and multigroups folder hierarchy, accepting a request via socket (or HTTP REST API even better).
This idea should be extended to any other functions handling folder or files manually via framework and delegate these tasks to an unique Wazuh daemon.