Exceto quando setuid e setgid bit são definidos, as permissões de um arquivo executável não determinam o contexto de segurança do processo baseado nesse arquivo.
Por exemplo, /bin/ls é de propriedade de root ; mas não tem permissões especiais por causa disso. Quando o usuário joe types ls , o ls process é executado com as credenciais do usuário joe .
Aplicativos que são para todos os usuários devem ser instalados para que todos os usuários tenham permissões para executar os executáveis e todos os dados de configuração globais sejam legíveis para os usuários. Nenhum desses materiais deve ser gravável. (Por exemplo, configuração em /etc , dados estáticos em /usr/share/<appname> (convenção GNU / Linux).
Um aplicativo deve salvar suas preferências de usuário local em alguma área legível e gravável para o usuário, como um arquivo de configuração em seu diretório inicial. Se um aplicativo não puder salvar automaticamente, isso provavelmente não é um problema com a permissão em seus materiais de instalação. Em vez disso, ele está tentando salvar automaticamente em um local em que o usuário solicitante não tem permissão ou em um local que não existe (um caminho com um ou mais componentes de diretório que não existem). Isso pode ser uma questão de algo na configuração local ou global.
Se você estiver com problemas de permissão intrigantes em um programa e não estiver claro o que ou onde ele está tentando acessar, uma maneira de descobrir o que está acontecendo é executar o aplicativo em um sistema chame utilitário de rastreamento como strace em sistemas GNU / Linux ou truss no Solaris. (A partir de um terminal console ou janela, ou então com os rastreamentos redirecionados para um arquivo.) Quando o problema de permissão se reproduzir, procure por falhas nas chamadas do sistema relacionadas ao acesso ao sistema de arquivos próximo ao final do rastreio.