View Issue Details

IDProjectCategoryView StatusLast Update
0007582Kali LinuxKali Package Improvementpublic2023-10-10 12:23
Reportervanguard Assigned Tosbrun  
Status closedResolutionfixed 
Product Version2022.1 
Fixed in Version2022.2 
Summary0007582: gvm is interfering with gvmd

Dear package team,

I stumbled over a little issue with the package gvm.


Im package gvmd you find the scripts


and these are used by the script "gvm-feed-update" of package gvm.
As you know, the latter one is run in with the user _gvm, so that all user rights are correct set.

However, when you start the "greenbone-*" script as root, then this is working well, but the result of the downloaded files are set with root:root instead of _gvm:_gvm.

I do not need to tell you,. that this is desciribed in README.Debian of package gvm.

However, if one did not read or know this, he will get into trouble caused by the wrong ownerships.

Ok, this can be manually fixed, but my writing here aims to suggest, to find a way, that these "greenbone-*" could not be executed, when the script "gvm-feed-update" is installed, just to force, only this script has to be used.

One idea might be, to put all scripts into one package (gvm or gvmd does not matter which, they are dependend), or

check, let the greenbone-scriptts check, if gvm-feed-update is existent, then, if yes, stop execution and give out a warning or

let greenbone-* installed without exec bit and let gvm-feed-update set the exec-bit at instrall or at first start.

You know, what I want to forbid.

If you decide, that everything is ok, how it is, just close this bug and drop me an info.

Thanks for reading this.

Best regards





2022-02-15 15:52

reporter   ~0015742

There is another thing, I noticed at the script "gvm-feed-update":

Whilst the mentioned "greenbone-*-sync" is just fetching only the differences between installed and repository,
the gvm-feed-update script is fetching the whole feed every time it is started.

Could not see, why, but this behaviour appeared also in the greenbone-* script, but in those this was fixed a few months ago.

If someone is interested in this issue.....

Best regards




2022-02-16 19:04

reporter   ~0015749

Please check my last note carefully. I rechecked today, and it did not appear, that the repo is fully cloned again. Maybe this was just by chance or this issue disappeared. However, I will take a look at it in the future. Would be nice, if someone could confirm or deny this issue, too.





2022-02-18 17:53

reporter   ~0015767

So, rechecked several times again, and yes, it still downloads the repo again and again and not the differs. This is just a besides information and not the core of this bugreport!

The main core of this bugreport is the content of my first mail (gvm interfering gvmd).

However, thanks for reading though.

Best regards




2022-02-28 14:16

manager   ~0015821

Thanks for the report.

The openvas-scanner package provides the script "greenbone-nvt-sync". The script can't be run by the "root". It's a block made by upstream. In Debian/Kali we just add an information about the user _gvm.

The gvmd package provides the scripts "greenbone-certdata-sync", "greenbone-scapdata-sync", "greenbone-feed-sync". These scripts can be run by root.
Upstream provides a way to force the script to be run as a specific user if it's first run as root (DROP_USER). I think to define this specific user in Kali/Debian to _gvm. So if the scripts are run as root, the scripts will be automatically restarted as user _gvm.
It should fix the "main" issue.

About the second issue I haven't investigated yet.



2022-03-10 14:31

manager   ~0015842

gvm version 21.4.4.~kali1 is now available in kali-rolling. The main issue should be fixed in this version.

About the second issue, I was unable to reproduce it:
from what I see the command gvm-feed-update only fetched the diff. But I think the included command greenbone-nvt-sync often downloads a lot of new data.
Can you specify which repo is entirely downloaded / which command caused the problem?



2022-04-21 16:12

manager   ~0016061

Main issue has been fixed.
I don't reproduce the second issue.

Issue History

Date Modified Username Field Change
2022-02-15 15:09 vanguard New Issue
2022-02-15 15:52 vanguard Note Added: 0015742
2022-02-16 10:09 sbrun Assigned To => sbrun
2022-02-16 10:09 sbrun Status new => assigned
2022-02-16 19:04 vanguard Note Added: 0015749
2022-02-18 17:53 vanguard Note Added: 0015767
2022-02-28 14:16 sbrun Note Added: 0015821
2022-03-10 14:31 sbrun Note Added: 0015842
2022-03-25 13:58 g0tmi1k Severity tweak => minor
2022-04-21 16:12 sbrun Status assigned => resolved
2022-04-21 16:12 sbrun Resolution open => fixed
2022-04-21 16:12 sbrun Fixed in Version => 2022.2
2022-04-21 16:12 sbrun Note Added: 0016061
2023-10-10 12:23 vanguard Status resolved => closed