Início / unix / Perguntas / 502857
Accepted
Crouching Kitten
Asked: 2019-02-26 03:50:04 +0800 CST

Existe um arquivo que sempre existe e um usuário 'normal' não pode lstatá-lo?

  • 772

Eu preciso disso para um teste de unidade. Existe uma função que faz lstat no caminho do arquivo passado como parâmetro. Eu tenho que acionar o caminho do código onde lstatfalha (porque a cobertura do código tem que chegar a 90%)

O teste pode ser executado apenas em um único usuário, portanto, eu queria saber se há um arquivo no Ubuntu que sempre existe, mas os usuários normais não têm acesso de leitura a ele ou à sua pasta. (Então lstat, falharia, a menos que fosse executado como root.)

Um arquivo inexistente não é uma solução, porque existe um caminho de código separado para isso, que já estou acionando.

EDIT: A falta de acesso de leitura ao arquivo apenas não é suficiente. Com isso lstatainda pode ser executado. Consegui acioná-lo (na minha máquina local, onde tenho acesso root), criando uma pasta em /root e um arquivo nela. E definindo a permissão 700 na pasta. Então, estou procurando um arquivo que está em uma pasta que só é acessível pelo root.

linux ubuntu

3 respostas

  1. Best Answer

    Em sistemas Linux modernos, você deve poder usar /proc/1/fdinfo/0(informações para o descritor de arquivo 1 (stdout) do processo de id 1 ( initno namespace root pid que deve ser executado como root)).

    Você pode encontrar uma lista com (como um usuário normal):

    sudo find /etc /dev /sys /proc -type f -print0 |
  perl -l -0ne 'print unless lstat'

    (remova -type fse você não quiser restringir a arquivos regulares).

    /var/cache/ldconfig/aux-cacheé outro candidato em potencial se você só precisa considerar os sistemas Ubuntu. Ele deve funcionar na maioria dos sistemas GNU, pois /var/cache/ldconfigé criado como leitura+gravação+pesquisável para root apenas pelo ldconfigcomando que vem com a GNU libc.

    • 21

  2. Olhando para a página de manual lstat(2) , você pode obter alguma inspiração em casos que podem fazer com que ele falhe com erros diferentes de ENOENT (arquivo não existe).

    A mais óbvia é:

    A permissão de pesquisa EACCES é negada para um dos diretórios no prefixo de caminho de path .

    Portanto, você precisa de um diretório no qual não possa pesquisar.

    Sim, você pode procurar um que já esteja em seu sistema (talvez /var/lib/privatese existir?) Mas você pode criar um você mesmo, com o equivalente a:

    $ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile

    A operação lstat(2) falhará com EACCES aqui. (Remover todas as permissões do diretório garante isso. Talvez você nem precise de muito e chmod -xremover as permissões de execução seria suficiente, já que as permissões de execução em um diretório são necessárias para acessar os arquivos sob ele.)

    Há outra maneira criativa de fazer o lstat(2) falhar, olhando para sua página de manual:

    ENOTDIR Um componente do prefixo do caminho do caminho não é um diretório.

    Portanto, tentar acessar um arquivo como esse /etc/passwd/nonexistentdeve acionar esse erro, que novamente é diferente de ENOENT ("Nenhum arquivo ou diretório") e pode atender às suas necessidades.

    Outra é:

    O caminho ENAMETOOLONG é muito longo.

    Mas você pode precisar de um nome muito longo para este (acredito que 4.096 bytes é o limite típico, mas seu sistema/sistema de arquivos pode ter um mais longo).

    Finalmente, é difícil dizer se algum deles será realmente útil para você. Você diz que quer algo que não acione o cenário "arquivo não existe". Embora normalmente isso signifique um erro ENOENT, na prática muitas verificações de nível superior simplesmente interpretarão quaisquer erros de lstat(2) como "não existe". Por exemplo test -e, ou o equivalente [ -e ...]do shell pode simplesmente interpretar todos os itens acima como "não existe", especialmente porque não há uma boa maneira de retornar uma mensagem de erro diferente e não retornar um erro implicaria que o arquivo existe, o que certamente não é o caso.

    • 12

  3. Você findmesmo pode.

    Usando /etc-- o diretório de arquivos de configuração como ponto de partida:

    sudo find /etc -type f -perm 0400 -user root

    No meu sistema, isso não retorna nada.

    Você pode ser um grupo menos restritivo e permitir root(somente o usuário rootdeve ser membro do grupo root) e procurar uma permissão de 440:

    sudo find /etc -perm 0440 -user root -group root

    No meu sistema isso retorna:

    /etc/sudoers.d/README
/etc/sudoers

    Editar:

    Com base na sua edição, você está procurando um diretório que não tenha permissão suficiente para que o usuário que está invocando impeça a listagem de diretórios:

    sudo find / -perm o-rwx -type d -user root -group root

    aqui estou procurando diretórios ( -type d) que não possuem os bits de permissão de leitura-gravação-execução para outros ( o-rwx) e são de propriedade de root:root.

    Tecnicamente, apenas a ausência do xbit execute ( ) impediria uma listagem de diretório ( lstat(2)) no diretório.

    Na saída que encontrei /run/systemd/inaccessible/no meu sistema baseado em init Systemd.

    Em relação aos arquivos em /proc, /sys, /dev:

    • Esses sistemas de arquivos são FS virtuais, ou seja, eles residem na memória, não no disco

    • Se você planeja confiar em /proc, use /proc/1/ou seja, confie em algo sob o PID 1, não quaisquer PIDs posteriores para ter confiabilidade/consistência, pois os PIDs (processos) posteriores não são garantidos.

    • 6

relate perguntas