ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-11397

item system.hw.chassis[vendor] [m|ZBX_NOTSUPPORTED]

    Details

      Description

      Hello,

      We are trying to use item system.hw.chassis[vendor] to populate the vendor filed of the host inventory, it works on our virtual dev environment but not on the production servers.

      sorry if this has been covered before but i have not found a working solution in older posts.

      in our agent conf file we do have AllowRoot=1 and when running dmidecode we do get system informations.

      Any suggestions?

      Thank you!

      # zabbix_agentd -f -t system.hw.chassis[vendor]
      system.hw.chassis[vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.]
      
      #dmidecode -q 
      ...
      Base Board Information
      Manufacturer: HP
      Product Name: ProLiant DL360 Gen9
      Version: Not Specified
      Serial Number: ...
      
      Chassis Information
      Manufacturer: HP
      Type: Rack Mount Chassis
      Lock: ...
      

        Activity

        Hide
        richlv added a comment -

        to clarify, are you running agent as root ?
        does it work if you start the agent daemon as root and then query it with zabbix_get ?

        Show
        richlv added a comment - to clarify, are you running agent as root ? does it work if you start the agent daemon as root and then query it with zabbix_get ?
        Hide
        Dominique Geoffrion added a comment - - edited

        yes even running as root does not work
        compute-1.qa-site1:~$ ps -ef | grep zabbix
        root 2049 1 0 Oct25 ? 00:00:00 /usr/sbin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf
        root 2050 2049 0 Oct25 ? 00:01:15 /usr/sbin/zabbix_agentd: collector [idle 1 sec]
        root 2051 2049 0 Oct25 ? 00:00:00 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]
        root 2052 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]
        root 2053 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]
        root 2054 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]
        root 2055 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: active checks #2 [idle 1 sec]

        compute-1.qa-site1:~$ grep AllowRoot /etc/zabbix/zabbix_agentd.conf
        AllowRoot=1

        compute-1.qa-site1:~$ sudo zabbix_agentd -f -t system.hw.chassis[vendor]
        system.hw.chassis[vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.]

        compute-1.qa-site1:~$ zabbix_agentd -f -t system.hw.chassis[vendor]
        system.hw.chassis[vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.]

        Show
        Dominique Geoffrion added a comment - - edited yes even running as root does not work compute-1.qa-site1:~$ ps -ef | grep zabbix root 2049 1 0 Oct25 ? 00:00:00 /usr/sbin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf root 2050 2049 0 Oct25 ? 00:01:15 /usr/sbin/zabbix_agentd: collector [idle 1 sec] root 2051 2049 0 Oct25 ? 00:00:00 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection] root 2052 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection] root 2053 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection] root 2054 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec] root 2055 2049 0 Oct25 ? 00:00:01 /usr/sbin/zabbix_agentd: active checks #2 [idle 1 sec] compute-1.qa-site1:~$ grep AllowRoot /etc/zabbix/zabbix_agentd.conf AllowRoot=1 compute-1.qa-site1:~$ sudo zabbix_agentd -f -t system.hw.chassis [vendor] system.hw.chassis [vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.] compute-1.qa-site1:~$ zabbix_agentd -f -t system.hw.chassis [vendor] system.hw.chassis [vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.]
        Hide
        richlv added a comment -

        a couple of things to try :

        • running daemon at debuglevel 4 and querying with zabbix_get
        • stracing it
        Show
        richlv added a comment - a couple of things to try : running daemon at debuglevel 4 and querying with zabbix_get stracing it
        Hide
        Dominique Geoffrion added a comment -

        ...
        mmap(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0xff000) = 0x7f04b2f36000
        munmap(0x7f04b2f36000, 4096) = 0
        mmap(NULL, 4112, PROT_READ, MAP_SHARED, 4, 0xff000) = -1 EPERM (Operation not permitted)
        close(4) = 0
        write(1, "system.hw.chassis[vendor] "..., 105system.hw.chassis[vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.]
        ) = 105
        close(3) = 0
        exit_group(0) = ?
        +++ exited with 0 +++

        Show
        Dominique Geoffrion added a comment - ... mmap(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0xff000) = 0x7f04b2f36000 munmap(0x7f04b2f36000, 4096) = 0 mmap(NULL, 4112, PROT_READ, MAP_SHARED, 4, 0xff000) = -1 EPERM (Operation not permitted) close(4) = 0 write(1, "system.hw.chassis [vendor] "..., 105system.hw.chassis [vendor] [m|ZBX_NOTSUPPORTED] [Cannot obtain hardware information.] ) = 105 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++
        Hide
        richlv added a comment -

        which distro, kernel ?
        is something like grsecurity in use ?

        i don't think zabbix can do much about being denied permission, except maybe having a more user-friendly error message

        Show
        richlv added a comment - which distro, kernel ? is something like grsecurity in use ? i don't think zabbix can do much about being denied permission, except maybe having a more user-friendly error message
        Hide
        Dominique Geoffrion added a comment - - edited

        we are running a Ubuntu xenial 16.04.1

        syslog ->

        Oct 26 16:23:30 compute-1.qa-site1 sudo: ansible : TTY=pts/0 ; PWD=/home/ansible ; USER=root ; COMMAND=/usr/bin/zabbix_get -s127.0.0.1 -p10050 -k system.hw.chassis[vendor]
        Oct 26 16:23:30 compute-1.qa-site1 kernel: [85689.741863] Program zabbix_agentd tried to access /dev/mem between ff000->101000.
        Oct 26 16:23:35 compute-1.qa-site1 kernel: [85694.234861] Program zabbix_agentd tried to access /dev/mem between ff000->101000.
        Oct 26 16:23:36 compute-1.qa-site1 kernel: [85695.247970] Program zabbix_agentd tried to access /dev/mem between ff000->101000.

        Show
        Dominique Geoffrion added a comment - - edited we are running a Ubuntu xenial 16.04.1 syslog -> Oct 26 16:23:30 compute-1.qa-site1 sudo: ansible : TTY=pts/0 ; PWD=/home/ansible ; USER=root ; COMMAND=/usr/bin/zabbix_get -s127.0.0.1 -p10050 -k system.hw.chassis [vendor] Oct 26 16:23:30 compute-1.qa-site1 kernel: [85689.741863] Program zabbix_agentd tried to access /dev/mem between ff000->101000. Oct 26 16:23:35 compute-1.qa-site1 kernel: [85694.234861] Program zabbix_agentd tried to access /dev/mem between ff000->101000. Oct 26 16:23:36 compute-1.qa-site1 kernel: [85695.247970] Program zabbix_agentd tried to access /dev/mem between ff000->101000.
        Hide
        Vladislavs Sokurenko added a comment -

        It should be related to this:
        /dev/mem protection

        Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM).

        https://wiki.ubuntu.com/Security/Features#dev-mem

        Show
        Vladislavs Sokurenko added a comment - It should be related to this: /dev/mem protection Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM). https://wiki.ubuntu.com/Security/Features#dev-mem
        Hide
        Dominique Geoffrion added a comment - - edited

        Thank you very much for taking the time to help us on this matter.

        As further tests done by our team we ran a strace on dmidecode and it is not reading from /dev/mem.

        It is reading from /sys/firmware/dmi/tables/smbios_entry_point which might explain why dmidecode is running fine and not zabbix_agentd for this key.

        Thank You

        Vladislavs Sokurenko I confirm that zabbix_agentd reads from /dev/mem but latest dmidecode version from:
        "/sys/firmware/dmi/tables/DMI" and "/sys/firmware/dmi/tables/smbios_entry_point"
        As you probably see /dev/mem cannot be opened anymore.

        Show
        Dominique Geoffrion added a comment - - edited Thank you very much for taking the time to help us on this matter. As further tests done by our team we ran a strace on dmidecode and it is not reading from /dev/mem. It is reading from /sys/firmware/dmi/tables/smbios_entry_point which might explain why dmidecode is running fine and not zabbix_agentd for this key. Thank You Vladislavs Sokurenko I confirm that zabbix_agentd reads from /dev/mem but latest dmidecode version from: "/sys/firmware/dmi/tables/DMI" and "/sys/firmware/dmi/tables/smbios_entry_point" As you probably see /dev/mem cannot be opened anymore.
        Hide
        Vladislavs Sokurenko added a comment -

        Fixed in development branch:
        svn://svn.zabbix.com/branches/dev/ZBX-11397

        Tested on kernel version 2.4.7-10 where sysfs is not available and 4.4.0-45-generic where sysfs is available but /dev/mem is not.

        Changed key system.hw.chassis to read DMI tables through sysfs instead of /dev/mem which can be denied due to security reasons.
        If reading from sysfs fails will fall back to /dev/mem.

        Show
        Vladislavs Sokurenko added a comment - Fixed in development branch: svn://svn.zabbix.com/branches/dev/ZBX-11397 Tested on kernel version 2.4.7-10 where sysfs is not available and 4.4.0-45-generic where sysfs is available but /dev/mem is not. Changed key system.hw.chassis to read DMI tables through sysfs instead of /dev/mem which can be denied due to security reasons. If reading from sysfs fails will fall back to /dev/mem.
        Show
        Vladislavs Sokurenko added a comment - - edited (1) [D] Documentation should state that this key depends on the availability of the SMBIOS table in sysfs, or in memory if not available through sysfs. Vladislavs Sokurenko Updated pages: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/zabbix_agent https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/zabbix_agent https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/zabbix_agent https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/zabbix_agent https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew2216 https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew306 https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew322 Alexander Vladishev Thanks! CLOSED
        Hide
        Sergejs Paskevics added a comment - - edited

        (2) I think better not to change the order of processing, I mean, firstly need to read from /dev/mem (how it was done before) and if agent cannot read from /dev/mem, then need to read from /sys/firmware/dmi/tables.

        Sergejs Paskevics Firstly need to read from /sys/firmware/dmi/tables.
        WON'T FIX

        Show
        Sergejs Paskevics added a comment - - edited (2) I think better not to change the order of processing, I mean, firstly need to read from /dev/mem (how it was done before) and if agent cannot read from /dev/mem , then need to read from /sys/firmware/dmi/tables . Sergejs Paskevics Firstly need to read from /sys/firmware/dmi/tables . WON'T FIX
        Hide
        Sergejs Paskevics added a comment - - edited

        (3) File SYS_TABLE_FILE doesn't close if lseek returns error.

        Vladislavs Sokurenko RESOLVED in r63727

        Sergejs Paskevics CLOSED

        Show
        Sergejs Paskevics added a comment - - edited (3) File SYS_TABLE_FILE doesn't close if lseek returns error. Vladislavs Sokurenko RESOLVED in r63727 Sergejs Paskevics CLOSED
        Hide
        Sergejs Paskevics added a comment - - edited

        (4) Necessary to add additional checks for lseek and read calls.

        Vladislavs Sokurenko RESOLVED in r63778

        Sergejs Paskevics Please review minor style fixes in r63805.
        Vladislavs Sokurenko CLOSED

        Show
        Sergejs Paskevics added a comment - - edited (4) Necessary to add additional checks for lseek and read calls. Vladislavs Sokurenko RESOLVED in r63778 Sergejs Paskevics Please review minor style fixes in r63805. Vladislavs Sokurenko CLOSED
        Hide
        Vladislavs Sokurenko added a comment -

        Fixed in:
        2.2.16rc1 r63826
        3.0.6rc1 r63827
        3.2.2rc1 r63829
        3.3.0 (trunk) r63830

        Show
        Vladislavs Sokurenko added a comment - Fixed in: 2.2.16rc1 r63826 3.0.6rc1 r63827 3.2.2rc1 r63829 3.3.0 (trunk) r63830
        Hide
        Vladislavs Sokurenko added a comment - - edited

        (5) CID 154396: Security best practices violations (TOCTOU) reported by Coverity scan.
        Vladislavs Sokurenko RESOLVED in development branch svn://svn.zabbix.com/branches/dev/ZBX-11397

        Sergejs Paskevics Successfully tested.
        CLOSED

        Show
        Vladislavs Sokurenko added a comment - - edited (5) CID 154396: Security best practices violations (TOCTOU) reported by Coverity scan. Vladislavs Sokurenko RESOLVED in development branch svn://svn.zabbix.com/branches/dev/ZBX-11397 Sergejs Paskevics Successfully tested. CLOSED
        Hide
        Vladislavs Sokurenko added a comment - - edited

        Fixed in:
        2.2.16rc1 r64002
        3.0.6rc1 r64003
        3.2.2rc1 r64004
        3.3.0 (trunk) r64005

        Show
        Vladislavs Sokurenko added a comment - - edited Fixed in: 2.2.16rc1 r64002 3.0.6rc1 r64003 3.2.2rc1 r64004 3.3.0 (trunk) r64005
        Hide
        Vladislavs Sokurenko added a comment - - edited

        Vladislavs Sokurenko When stat was changed to fstat it was forgotten to close file in case fstat fails, even if fstat should not fail it is better to fix.
        RESOLVED in r64001

        Sergejs Paskevics Looks good.
        CLOSED

        Show
        Vladislavs Sokurenko added a comment - - edited Vladislavs Sokurenko When stat was changed to fstat it was forgotten to close file in case fstat fails, even if fstat should not fail it is better to fix. RESOLVED in r64001 Sergejs Paskevics Looks good. CLOSED

          People

          • Assignee:
            Unassigned
            Reporter:
            Dominique Geoffrion
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: