Como obter informações de dmidecode sem privilégios de root?

Estou escrevendo um programa que exibe várias informações do sistema (em um sistema CentOS). Por exemplo, o tipo e a velocidade do processador (de /proc/cpuinfo), o último tempo de inicialização (calculado de /proc/uptime), o endereço IP (de ifconfigsaída) e uma lista de impressoras instaladas (de lpstatsaída).

Atualmente, vários dados são obtidos do dmidecodeprograma:

• O tipo de plataforma ( dmidecode -s system-product-name)
• A versão do BIOS ( dmidecode -s bios-version)
• A quantidade de memória física ( dmidecode -t17 | grep Size)

Eles estarão disponíveis apenas se meu programa for executado como root (caso contrário, o dmidecodesubprocesso falhará com um /dev/mem: Permission deniederro). Existe uma maneira alternativa de obter essas informações que um usuário normal possa acessar?

Acabei de verificar no meu sistema CentOS 5 - depois:

chgrp kmem /usr/sbin/dmidecode
chmod g+s /usr/sbin/dmidecode

Ainda não é possível fazer o dmidecode funcionar - o grupo kmem possui apenas direitos de leitura para / dev / mem - parece que há uma gravação envolvida para obter as informações do BIOS.

Então, outras opções:

1. Use sudo
2. Use outras fontes de informação (por exemplo, / proc / meminfo)
3. Use um script init que grave a saída estática de dmidecode em um arquivo legível por todo o mundo

Algumas das informações apresentadas por dmidecodeestão disponíveis em /sys/devices/virtual/dmi/id.

Outras informações podem ser obtidas por meio da análise /proc/cpuinfo, /proc/meminfoou /sys/system/node/node0/meminfo.

1. Eu posso ler informações de DMI como Usuário em /sys/class/dmi/id/. Não incluindo números de série (que exigem privilégios de root para ler).

   Eu acho que esse é o comportamento pretendido pelos desenvolvedores de kernel que reconhecem a privacidade.

2. Em relação a dmesg: dmesgé um comando para acessar o buffer de anel do kernel. O buffer de anel implica que as informações mais antigas são substituídas pelas mais novas quando o buffer está "transbordando". Também está lendo a saída de depuração do módulo do kernel, que nunca foi concebida para ser analisável.

3. Para acessar a saída do kernel com systemdrun:

   journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
   

4. Em relação às respostas de david-homer's e nils : O arquivo /dev/memnão fornece apenas informações de memória, mas mapeia toda a memória física no espaço do usuário. Portanto, é possível acessar os endereços de memória DMI através dele (e fazer coisas muito mais desagradáveis).

5. Em relação chgrpe chmod g+sde dmidecodein nils ' resposta : acho que isso não funcionará como pretendido, porque salvar gid com chmod g+snão faz dmidecodeuso de novos privilégios. dmidecodeprecisa ligar setegidpara definir seu ID de grupo efetivo antes que ele possa acessar /dev/mem. A julgar pelo código fonte, dmidecodenão faz isso.

Tente dmesg. Consegui obter as informações que queria dessa maneira com uma conta de usuário comum.

Estamos usando o DMIDecode para ler informações de sistemas Linux remotos e ainda não encontramos uma solução alternativa para isso. Registrei uma chamada na página inicial do dmidecode perguntando sobre isso ...

O uso do comando dmidecode -t system fornece o erro "/ dev / mem: Permissão negada", que é um problema, pois não queremos informações de memória (apenas fabricante, modelo e número de série).

Percebo que o comando smbios executado no SunOS funciona bem para essas informações sem a necessidade de privilégios de root.

Por enquanto, substituirei nossa documentação declarando "usar uma conta específica com o privilégio menos exigido" por "credenciais raiz do usuário".

lshal contém muitas dessas informações e não requer privilégios de root.

Não sei por que @mtneagle recebeu votos negativos.

Os três itens desejados pelo OP são:

O tipo de plataforma ( dmidecode -s system-product-name)
A versão do BIOS ( dmidecode -s bios-version)
A quantidade de memória física ( dmidecode -t17 | grep Size)

Podemos obter cada um destes assim:

dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "1"
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "2"
dmesg | grep "Memory:" | cut -d '/' -f '2-' | cut -d ' ' -f '1'

(Ou pelo menos aqueles que funcionam nos 4 servidores de hardware diferentes que eu tenho e não retornaram nada de maneira limpa para o BIOS ou o tipo de servidor em um convidado Xen.)

Perdi algo óbvio?

Atualização: Obrigado a @Ruslan por apontar o óbvio que eu perdi.

Citação:

Sim você tem. As mensagens do kernel são armazenadas em um buffer de anel. Quando muitas linhas foram impressas, as primeiras são excluídas.

Portanto, se sua máquina funcionou por várias semanas e você a suspendeu / reiniciou pelo menos todos os dias, há grandes chances de que as informações que você deseja aqui não estejam mais no buffer.

(Eu tenho uma situação assim com tempo de atividade de 18 dias aqui.) Talvez seja melhor investigar /var/log/kern.log

Algo como grep DMI: /var/log/kern.log | tail -n1

Para obter a quantidade total de memória física, você pode analisar /proc/meminfo, free, vmstat, etc. Você pode também analisar o buffer de mensagens do kernel, já que fala sobre ele em 0 tempo.

A versão do BIOS é mais difícil, não acredito que isso seja possível como usuário não root, mas posso estar errado. É possível que ele (e o nome do produto do sistema) seja exposto em algum lugar, talvez em /sys/ou /proc/, mas não consigo encontrar nada.

Nossos serviços Linux não são executados como raiz. No script de pós-instalação do RPM (que executa como root), instalamos um arquivo /etc/sudo.d e setcap alguns de nossos executáveis ​​(por exemplo, para privilégios de transmissão de rede).