
Estou trabalhando com um sistema de compilação que depende de caminhos absolutos para fazer referência a arquivos de origem, etc. Quando quero testar a construção com cadeias de ferramentas diferentes, monto o diretório src em VMs ou chroots. O problema é que o caminho para o meu diretório src na minha máquina host é muito complexo - digamos /a/b/c/d/src - e deve corresponder ao caminho montado.
Quero poder montar meu diretório src em algum lugar como /mnt/src, mas sempre acabo precisando criar um link simbólico /a/b/c/d/src para /mnt/src, ou apenas ter o ponto de montagem em /a/b/c/d/src diretamente.
Parece sujo ter /a/b/c/d no sistema de arquivos e, em geral, você pode nem ter permissão para criar arquivos em /a/b/c/d (ou em qualquer um dos diretórios pai). Existe alguma maneira de falsificar esse caminho para apaziguar meu sistema de compilação?
Responder1
A melhor solução seria ensinar ao sistema de construção que os caminhos de origem e de instalação não são a mesma coisa, mas presumo que você não pode fazer isso.
O método mais direto seria fazer com que o caminho de origem seja algo que possa ser facilmente reproduzido, como /var/tmp/mybuild
. Se o sistema de compilação não for muito desagradável, criar um link simbólico para onde os arquivos estão localizados deve ser suficiente. Se o sistema de compilação insistir em canonizar links simbólicos, você poderá enganá-lo usando ummontar montagemem vez de. Com o bindfs, você não precisa de privilégios de root, você só precisa ter permissão de gravação no local onde deseja que os arquivos apareçam.
Se você não puder agir no sistema de origem, uma abordagem alternativa épré-carregar uma biblioteca dinâmica que redirecione determinados acessos a arquivos. Isso pressupõe que todos os executáveis que estarão em execução estão vinculados dinamicamente. O código no exemplo vinculado demonstra como fazer isso a partir de um arquivo específico; ele pode ser ajustado para redirecionar todos os arquivos cujo caminho começa com um determinado prefixo. Substituir
if (!strcmp(path, FROM)) {
path = TO;
}
…
return ret;
por algo como (não testado)
char *other_path = NULL;
if (!strncmp(path, FROM, strlen(FROM))) {
other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
if (other_path == NULL) return -ENOENT; // return NULL in fopen
memcpy(other_path, TO, strlen(TO));
memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
path = other_path;
}
…
free(other_path);
return ret;
Responder2
Se o seu objetivo é evitar poluir "o host" com resíduos de compilações de teste, então construir dentro de um firejail
com sobreposição persistente deve ser uma boa opção. Dessa forma, ele seria construído, e talvez instalado, como se fosse real, mas os arquivos acabariam em uma sobreposição, em vez de poluir o sistema de arquivos "real".
Há a desvantagem de que você precisará localizar os resultados da construção de teste dentro da sobreposição, mas ao mesmo tempo isso tem a possível vantagem de preservar resultados sucessivos de construção de teste, por exemplo, para compará-los ou qualquer outra análise forense posterior que você possa precisar. fazer.