Ocultar ou mascarar o diretório de um processo no OS-X

1

Existe um método para um processo (sem raiz) para se esconder ou montar sobre um caminho do sistema de arquivos para si mesmo? Não deve afetar o sistema de arquivos real, apenas o processo em si e talvez seus filhos?

Bit de um caso de uso estranho, mas preciso construir algo em um servidor de compilação OSX como se fosse uma máquina OSX comum. No entanto infelizmente existem algumas bibliotecas instaladas em /usr/local/{include,lib} que atrapalham a compilação e eu não tenho root na máquina. Por isso, gostaria de ocultar temporariamente /usr/local durante a execução de configure e make .

Não tenho acesso de gravação a /usr/local , por isso não posso modificá-lo.

    
por Jeroen 09.08.2016 / 10:46

4 respostas

1

Não, não há uma maneira direta de fazer isso. Você pode usar chflags hidden para esconder coisas do Finder , mas isso não afeta a linha de comando.

A solução dependeria do script de configuração. É possível que simplesmente observe PATH para notar o /usr/local , mas é mais provável que ele tenha uma lista de diretórios codificados para analisar, incluindo /usr/local . Para contornar o antigo ( PATH -based), você pode ajustar seu caminho. Para o último, a única coisa que funciona é modificar o script configure .

O motivo pelo qual você verá listas codificadas é que os complementos não podem usar os mesmos caminhos de pesquisa que o restante do sistema. Por exemplo, as várias portas BSD podem usar /usr/pkg , /usr/local , etc., e parcialmente dependem dos empacotadores para definir esses nomes de caminho em seus scripts de construção. Mas os programas que não são construídos como parte do sistema de portas precisam procurar coisas nesses locais, para construir com pouca atenção do usuário.

Se você quiser substituir o caminho de pesquisa padrão do OSX, comece com a página de manual ld , que diz

Search paths
ld maintains a list of directories to search for a library or framework to use. The default library search path is /usr/lib then /usr/local/lib. The -L option will add a new library search path. The default framework search path is /Library/Frameworks then /System/Library/Frameworks. (Note: previously, /Network/Library/Frameworks was at the end of the default path. If you need that functionality, you need to explicitly add -F/Network/Library/Frameworks). The -F option will add a new framework search path. The -Z option will remove the standard search paths. The -syslibroot option will prepend a prefix to all search paths.

e você pode passar opções para ld prefixando-as com -Wl (e usando uma vírgula onde um espaço é necessário). Para o seu propósito, você escreveria um script que

  • usa -Z para remover os caminhos de pesquisa e
  • adicione novamente as partes que você precisa usando -L

O clang option -v mostra os detalhes do compilador front-end e passa -v para ld , por exemplo, usando -Wl,-v mostra o linker do detalhes.

Algo parecido com isto, por exemplo:

#!/bin/sh
clang -Wl,-Z -L/usr/lib -F/Library/Frameworks -F/System/Library/Frameworks "$@"

Ele não está documentado no manual clang , mas uma verificação rápida mostra que ele passaria uma opção -Z simples para o vinculador. Por outro lado, clang faz opções de documentos (principalmente para compatibilidade com o gcc) que suprimem suas pesquisas de diferentes categorias de diretórios de inclusão:

   -nostdinc
          Do not  search  the  standard  system  directories  or  compiler
          builtin directories for include files.

   -nostdlibinc
          Do not search the standard system directories for include files,
          but do search compiler builtin include directories.

   -nobuiltininc
          Do not search clang's builtin directory for include files.

Ele não tem uma opção para mostrar o caminho de pesquisa para arquivos de inclusão, mas você pode inferir isso executando o pré-processador.

Assim que o script estiver funcionando, executando o script configure , defina CC para o nome desse script, por exemplo,

./configure CC=cc-system

Eu tenho feito isso há algum tempo, mas não precisei dessa combinação em particular (veja wrappers do Compiler ).

    
por 09.08.2016 / 10:57
1

Assumindo que os processos estão cooperando (ou seja, eles não tentam deliberadamente contornar o esconderijo) e que eles são dinamicamente vinculados, você pode usar DYLD_PRELOAD (esse é o nome OSX, a maioria das outras variantes do Unix chamam de LD_PRELOAD ) para carregar uma biblioteca que envolve as funções de pesquisa de arquivos e falsifica alguns resultados.

Aqui é um exemplo de código que não aproximadamente o que você quer. Dependendo de como os programas executados acessam os arquivos que você não deseja que eles vejam, talvez seja necessário substituir outras funções, possivelmente open ou access .

    
por 10.08.2016 / 01:03
0

Assim, você não quer esconder certos diretórios, mas apenas garantir que o script configure não encontre determinados arquivos nesse diretório.

A maneira mais fácil de realizar isso é provavelmente abrir configure.ac em um editor e editá-lo para que ele não procure por arquivos de inclusão ou bibliotecas em /usr/local e, em seguida, gere novamente o script configure . Como alternativa, você também pode editar configure diretamente, já que é apenas um script de shell. No entanto, isso será um pouco mais complicado, já que o script é gerado.

    
por 09.08.2016 / 11:00
0

Dependendo da biblioteca que a compilação está obtendo e de como o script configure está configurado, talvez seja possível desativar o uso informando configure para não usar esse "pacote externo" que forneceu a biblioteca ou procurá-lo em outro caminho.

A maneira de fazer isso com configure geralmente é dizer

$ ./configure --without-PACKAGE

para desativar o uso do pacote ou

$ ./configure --with-PACKAGE=PATH

para apontar para outro caminho no qual ele está instalado, onde PACKAGE é o "pacote externo" que fornece a biblioteca e PATH é o caminho de prefixo no qual o pacote foi instalado.

Outra solução seria configurar uma máquina virtual com a mesma configuração que a máquina de destino e construir lá.

    
por 09.08.2016 / 11:38