Maneira correta de dar privilégios elevados ao aplicativo mono?

Question

Eu tenho um aplicativo mono (no Ubuntu) que ata / var / log / messages e pega inserções USB, e se esse dispositivo estiver em uma certa porta, precisa particioná-lo, formatá-lo e montá-lo. Obviamente, isso requer permissões de root. Eu sou novo no Linux, e estou querendo saber o que a maneira "correta" é conseguir isso.

É melhor executar meu aplicativo como root o tempo todo? Ou é melhor (ou possível) dar minhas permissões de aplicativo para desmontar , parted , mkfs e mount e qualquer outro processo somente de raiz que eu preciso?

Antecedentes:
Depois de montados, alguns arquivos solicitados por clientes específicos serão carregados na unidade. Cada unidade é única, portanto a clonagem não funcionará e suportarei centenas de unidades por semana, portanto, preciso que ela seja o mais automatizada possível. Eu percebo que isso é perigoso, então sim, vou colocar um aviso na máquina de que todas as unidades serão formatadas. Eu estou usando mono porque se encaixa muito bem com o aplicativo maior que está escrito em c # .net.

    

Answer 1

Na verdade, você não precisa ter permissões de root para fazer isso. Se fato eu recomendaria altamente não deixar nada correr como root. Aqui está a maneira mais segura que eu sugeriria.

1. Escreva um shell script de uma linha que execute chown no nó do dispositivo para o usuário em que seu aplicativo mono está sendo executado ou chmod para abrir permissões mundiais ou de grupo suficientes para que seu aplicativo modifique o dispositivo.
2. Salve o script em /usr/local/bin de propriedade de root e NÃO seja gravável pelos usuários.
3. Adicione uma regra ao sudoers que permita ao usuário que seu aplicativo mono execute o script que você acabou de criar.
4. No seu aplicativo depois que ele detectar um dispositivo, primeiro execute esse script com sudo para que o dispositivo seja lido / gravável pelo seu usuário.
5. Faça todas as suas ações no dispositivo como usuário!

Observação: não conceda ao seu aplicativo sudo acesso a chmod , chown , fdisk ou qualquer outra ferramenta administrativa, apenas o script de propósito único protegido que você escreveu que abre permissões apenas em um único dispositivo. / p>     

Answer 2

Adicionando à resposta do Caleb, para mount e umount você não precisará de privilégios de administrador para fazer isso, desde que configure /etc/fstab com os nomes de dispositivos e pontos de montagem para cada usuário "noauto" ( além de qualquer outra opção que você precisa. user dá aos usuários normais permissão para montar e desmontar o dispositivo, noauto diz ao processo de inicialização para não tentar montar todos eles na inicialização ... o fsck e dump colunas devem ser 0, também). Você precisará criar uma entrada e um diretório para cada dispositivo (por exemplo, /mnt/sda1 para ir com /dev/sda1 ).

Se estes forem formatados em FAT, você poderá ignorar a montagem completamente. Depois de usar mkfs.msdos para criar o sistema de arquivos, use mtools para editar o sistema de arquivos diretamente. Examinando a documentação do mtools, há pelo menos um arquivo temporário (achei .mcwd ) que dificulta o trabalho com vários sistemas de arquivos ao mesmo tempo (cada processo precisará definir uma variável de ambiente $MCWD exclusiva para apontar para um diferente local ou nome do arquivo para este arquivo), então leia a documentação completamente.

Com o sistema de arquivos ext2, uma nova lata de worms é aberta: propriedade de usuário e grupo e permissões de arquivo. A maneira mais fácil de contornar isso é usando um script para chown do ponto de montagem depois que o sistema de arquivos é montado, assim como o script, para chover o arquivo do dispositivo. Em seguida, o usuário pode gravar os arquivos e usar o chmod para definir as permissões adequadamente. O problema aqui é que o destinatário da unidade pode não ter um usuário correspondente, mas desde que você tenha certeza de que os "outros" bits de leitura / gravação / execução estejam corretos e evite usar os bits suid / sgid, isso é principalmente problema cosmético (a menos que eles realmente tenham um usuário que corresponda ao seu uid, e então essa pessoa poderá gravar na unidade a menos que o destinatário altere as permissões imediatamente).