Operating system: Kali Linux 2021
Installation method / source: sudo apt install openvas
This is a fresh installation of Kali and OpenVAS/GVM. It happens on two systems both with fresh installations from the standard Kali repository.
──(development㉿kali)-[~] └─$ gvm-cli socket --xml "<get_version/>" =ERROR:gvmtools.cli:[Errno 13] Permission denied ┌──(development㉿kali)-[~] └─$ sudo gvm-cli socket --xml "<get_version/>" 1 ⨯ [sudo] password for development: Traceback (most recent call last): File "/usr/bin/gvm-cli", line 33, in <module> sys.exit(load_entry_point('gvm-tools==21.6.1', 'console_scripts', 'gvm-cli')()) File "/usr/lib/python3/dist-packages/gvmtools/cli.py", line 64, in main do_not_run_as_root() File "/usr/lib/python3/dist-packages/gvmtools/helper.py", line 168, in do_not_run_as_root raise RuntimeError('This tool MUST NOT be run as root user.') RuntimeError: This tool MUST NOT be run as root user. ┌──(development㉿kali)-[~] └─$ gvm-cli socket --xml "<get_version/>" 1 ⨯ ERROR:gvmtools.cli:[Errno 13] Permission denied
Here is the output of the
┌──(development㉿kali)-[~] └─$ sudo gvm-check-setup gvm-check-setup 21.4.3 Test completeness and readiness of GVM-21.4.3 Step 1: Checking OpenVAS (Scanner)... OK: OpenVAS Scanner is present in version 21.4.3. OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem. Checking permissions of /var/lib/openvas/gnupg/* OK: _gvm owns all files in /var/lib/openvas/gnupg OK: redis-server is present. OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock OK: redis-server is running and listening on socket: /var/run/redis-openvas/redis-server.sock. OK: redis-server configuration is OK and redis-server is running. OK: _gvm owns all files in /var/lib/openvas/plugins OK: NVT collection in /var/lib/openvas/plugins contains 79260 NVTs. Checking that the obsolete redis database has been removed OK: No old Redis DB OK: ospd-OpenVAS is present in version 21.4.3. Step 2: Checking GVMD Manager ... OK: GVM Manager (gvmd) is present in version 21.4.4. Step 3: Checking Certificates ... OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem. OK: Your GVM certificate infrastructure passed validation. Step 4: Checking data ... OK: SCAP data found in /var/lib/gvm/scap-data. OK: CERT data found in /var/lib/gvm/cert-data. Step 5: Checking Postgresql DB and user ... OK: Postgresql version and default port are OK. gvmd | _gvm | UTF8 | en_US.UTF-8 | en_US.UTF-8 | OK: At least one user exists. Step 6: Checking Greenbone Security Assistant (GSA) ... Oops, secure memory pool already initialized OK: Greenbone Security Assistant is present in version 21.4.3. Step 7: Checking if GVM services are up and running ... OK: ospd-openvas service is active. OK: gvmd service is active. OK: greenbone-security-assistant service is active. Step 8: Checking few other requirements... OK: nmap is present in version 21.4.3. OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work. WARNING: Could not find makensis binary, LSC credential package generation for Microsoft Windows targets will not work. SUGGEST: Install nsis. OK: xsltproc found. WARNING: Your password policy is empty. SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy. It seems like your GVM-21.4.3 installation is OK.
I read from this post: Permission Denied When Running gvm-cli · Issue #291 · greenbone/gvm-tools · GitHub
This is not a permission error on gvmd side. As @y0urself already mentioned you don't have file system permissions to access the used unix domain socket. Therefore closing here.
But this is a fresh installation. So, shouldn’t the installer create the file with the correct permissions?
I added my user to the _gvm group:
sudo usermod -a -G _gvm development
but same error.
Can you please let me know what permissions are required for this file?
ls -lah /var/run/gvm/ total 4.0K drwxrwsr-x 2 _gvm _gvm 80 Dec 17 21:50 . drwxr-xr-x 39 root root 920 Dec 17 21:49 .. -rw------- 1 _gvm _gvm 5 Dec 17 21:50 gvmd.pid srw-rw---- 1 _gvm _gvm 0 Dec 17 21:50 gvmd.sock