The good thing is, that I was able to identify (and fix) the root cause. Apparently, the credentials Z assigned to the given target Y had no read (and also no write) permissions for the given group B. After granting read permissions for group B to credentials Z, I was able to start task X with user A.
I’m reporting this finding, as I believe that a segmentation fault prevention would be a good thing. Also a dedicated error message would improve finding the root cause.
It appears to be crashing somewhere, but we would need to run a debug build to see the root cause more clearly.
Could you provide step-by-step instructions on how to reproduce the issue? Alternatively, could you run the same test using a debug build and share the output or any error messages it produces? That would help identify the problem more accurately.
Hi @Eero,
thanks for your response.
Could I just pull the debug build by adapting my compose.yaml? E.g. by updating gvmd: image: ``registry.community.greenbone.net/community/gvmd:stable
If so, I could pull the image, restart and try to reproduce the situation, and immediately revert back to stable afterwards.
Just to mention: I am very limited in the URIs for the available images.
I don’t think a debug build is available there. If I remember correctly, I have a script on Debian that builds a debug version directly from source.
It’s not intended for a Docker-based environment, but I would expect the same issue to occur there as well. Running a debug build should provide more detailed diagnostic information and help pinpoint the root cause of the crash.
@pete can you share video with step by step instructions to re produce issue? I can then test it my debug build or can you test it with my environment?
Create an User “MyAdmin” with Role Admin with the Superadmin
Create a Credential (User/PW) “MyCredential” with MyAdmin
Create a Target “MyTarget” (Single IP, Ports: All IANA assigned TCP, Alive Test: ICMP Ping) which uses the previously created Credentials “MyCredential”
Create a task “MyTask” that scans the previously generated target “MyTarget” (everything else default values)
Create a user “MySubAdmin” with Role Admin
Start the task “MyTask” with user “MyAdmin”
Status: Task will be Requested, Queued and Run until completion
Logout user “MyAdmin”
Login as user “MySubAdmin”
Start the task “MyTask”
Status: Task will be Requested, Queued and Run until completion
Remark: my regularly updated greenbone instance ran w/o groups in this setup for months sucessfully. I then introduced groups:
Logout user “MySubAdmin”
Login user “MyAdmin”
Create a group “MyGroup” (enable '“Special Group”)
Add users “MyAdmin” and “MySubAdmin” to this group
For task “MyTask”, grant Write permissions to group “MyGroup” (i.e., get_tasks, modify_tasks, resume_tasks, start_task, stop_task)
For target “MyTarget”, grant Write permissions to group “MyGroup” (i.e., get_targets, modify_targets)
Logout user “MyAdmin”
Login as user “MySubAdmin”
Start task “MyTask”
Task will be Requested and immediately set to Interrupted at 0%. The log will show the segfault posted above
Logout user “MySubAdmin”
Login user “MyAdmin”
Grant read permissions for group “MyGroup” to credential “MyCredential” (i.e. get_credentials)
Logout user “MyAdmin”
Login as user “MySubAdmin”
Start the task “MyTask”
Status: Task will be Requested, Queued and Run until completion
I couldn’t reproduce this with the latest GitHub version — or I may have misunderstood the instructions. Just to confirm, does your machine have enough RAM and swap available, at least 16 GB?
Could you use this script to build a debug version of OpenVAS and verify whether the problem is reproducible?
Please make sure the system has 20 GB of RAM available. I’ve encountered many similar stack dumps in the past, and in a surprising number of cases they were caused by memory exhaustion rather than the underlying application itself. It would be good to eliminate that possibility first.
@Eero
I checked the resources of the (virtual) server - it seems that at the moment 16 GBs RAM are assigned, I will try to get more.
Once I got more RAM, I will try to reproduce the issue and report the result back here.
Unfortunately, I am limited in what I can do on this server as it is a managed server, where I have limited permissions only.
In the meantime, I will try to reproduce the problem on another machine. If I am able to reproduce, I will checkout the script you provided for building the custom build.
BR,
Peter
I would also recommend adding more swap space, for example by expanding the swap file. With 16 GB of physical memory, a swap file of at least 10 GB is a sensible baseline, especially for memory-intensive workloads, as it can help prevent out-of-memory situations and improve overall system stability.
Unfortunately, I am pretty limited on what I can download or execute on this machine, so I need to setup a separate machine with similar setup in order to create and run the custom build.
I just updated to the latest stable version (UI shows 28.4.0) and the behavior is gone.
I removed with an admin user every permission on the credential used by the target of interest, but kept permissions for a given group on the task and target itself.
I then logged out and logged in as another user with role ‘Admin’ (being member of the group I just removed permissions from the credential).
Now, the credential is still visible in the UI to the user (different behavior compared to 2 weeks ago) and I am able to run the scan task on the target.
Then I logged out and logged in as another user with role ‘User’ (being member of the group I just removed permissions from the credential).
Now, the credential is not visible in the UI to the user but I am also able to run the scan task on the target.
Task will be Requested and immediately set to Interrupted at 0%. The log will show the segfault posted above