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 ?

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.]

a couple of things to try :

• running daemon at debuglevel 4 and querying with zabbix_get
• stracing it

...
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 +++

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

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.

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

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

vso 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.

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.

(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.

vso 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

sasha Thanks! CLOSED

(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.

s.paskevics Firstly need to read from /sys/firmware/dmi/tables.
WON'T FIX

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

vso RESOLVED in r63727

s.paskevics CLOSED

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

vso RESOLVED in r63778

s.paskevics Please review minor style fixes in r63805.
vso CLOSED

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

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

s.paskevics Successfully tested.
CLOSED

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

vso 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

s.paskevics Looks good.
CLOSED