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

12

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 em /proc/uptime ), o endereço IP (de ifconfig output) e uma lista de impressoras instaladas (de lpstat output ).

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

  • 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 somente se meu programa for executado como raiz (porque, caso contrário, o subprocesso dmidecode falhará com um erro /dev/mem: Permission denied ). Existe uma maneira alternativa de obter essas informações, que um usuário normal pode acessar?

    
por user1024 08.11.2011 / 18:29

10 respostas

4

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 com que o dmidecode funcione - o grupo kmem tem apenas direitos de leitura para / dev / mem - parece que há uma gravação envolvida para obter as informações da BIOS.

Então, algumas outras opções:

  1. Use sudo
  2. Use outras fontes de informação (por exemplo, / proc / meminfo)
  3. Use um script init que grava a saída estática do dmidecode em um arquivo legível pelo mundo
por 08.11.2011 / 21:02
5

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

Outras informações podem ser obtidas analisando /proc/cpuinfo , /proc/meminfo ou /sys/system/node/node0/meminfo .

    
por 27.10.2015 / 00:46
5
  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 requerem privilégios de root para ler).

    Acho que esse é o comportamento pretendido pelos desenvolvedores de kernel com conhecimento de privacidade.

  2. Em relação a dmesg : dmesg é um comando para acessar o buffer de anel do kernel. O buffer de toque indica 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 systemd run:

    journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
    
  4. Em relação a david-homer e nils ' answers: O arquivo /dev/mem não fornece informações de memória, mas mapeia toda a memória física no espaço do usuário. Portanto, pode-se acessar endereços de memória DMI através dela (e fazer coisas muito mais desagradáveis).

  5. Em relação a chgrp e chmod g+s de dmidecode na resposta nils ': acho que isso não funcionará como planejado, porque salvar o gid com chmod g+s não faz dmidecode usar novos privilégios. dmidecode precisa chamar setegid para definir seu ID de grupo efetivo antes de poder acessar /dev/mem . A julgar pelo código-fonte, dmidecode não faz isso.

por 10.04.2016 / 16:19
4

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

Usando o comando dmidecode -t system, aparece o erro "/ dev / mem: Permission denied", que é um problema, pois não queremos informações de memória (apenas fabricante, modelo e número de série).

Noto que o comando smbios rodando no SunOS funciona bem para esta informação sem precisar de privilégios de root.

Por enquanto, vou substituir nossa documentação dizendo "use uma conta específica com o privilégio menos necessário" com "credenciais raiz do usuário".

    
por 26.04.2012 / 11:22
4

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

    
por 24.09.2013 / 22:01
4

Experimente o dmesg. Consegui obter as informações que queria desta forma com uma conta de usuário comum.

    
por 19.12.2013 / 20:37
3

Não sei por que @mtneagle foi derrotado.

Os três itens que o OP queria 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:

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 trabalham nos 4 servidores de hardware diferentes que eu tenho, e não retornaram nada para BIOS ou tipo de servidor em um convidado Xen.)

Eu perdi algo óbvio?

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

Citações:

Yes, you have. Kernel messages are stored in a ring buffer. When too many lines have been printed, first ones are deleted.

So if your machine has worked for multiple weeks, and you suspended/resumed it at least every day, high chances are that the information you grep for here will be no longer in the buffer.

(I have such a situation with uptime of 18 days here.) It may be better to look into /var/log/kern.log

Something like grep DMI: /var/log/kern.log | tail -n1

    
por 27.08.2016 / 17:33
2

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

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

    
por 09.11.2011 / 04:13
2

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

    
por 26.07.2013 / 10:28
0

Eu preciso ler o arquivo system-uuid de / sys / devices / virtual / dmi / id / product_uuid com uma conta não-root. Para alterar a permissão (no momento da inicialização) eu criei um arquivo /etc/tmpfiles.d/systemd-uuid.conf com o conteúdo:

z /sys/class/dmi/id/product_uuid 0444 - - - -

Todos podem ler este arquivo agora. Deve ser bastante simples de modificar para outros arquivos.

    
por 20.03.2018 / 13:36