Permissões de usuário/grupo no Windows 2012

Question

Gostaria de ter algumas sugestões sobre como as permissões no Windows-2012 podem ser configuradas para o seguinte caso de uso:

1. Cada usuário (vamos chamá-lo bob) executa uma aplicação (vamos chamá-la myapp).
2. myapprequer permissões de leitura/gravação para todos os arquivos e pastas em c:\Users\bob\myapp(1)
3. bobrequer permissões de leitura/gravação em c:\Users\bob\myapp\templates.
4. bobnão consigo ler a pastac:\Users\bob\myapp\logs
5. Por padrão e a menos que especificado em 3 e 4, bobpode ler qualquer arquivo e pasta emc:\Users\bob\myapp\

Minha formação é Linux e não tenho certeza de como organizar isso em um Windows Server.

Eu apreciaria se alguém pudesse me indicar a direção certa!

(1) Eu inventei o caminho. Estará em algum lugar nas janelas. (Não acho que seja importante, mas se for, compartilhe seu conhecimento!)

EDIT: Solução no Linux

• O aplicativo é executado em usuário bobapp, grupo bobapp.
• O usuário é executado sob o usuário bob, que faz parte do grupobobapp
• Todos os arquivos e pastas /users/bob/myapppertencem ao usuário bobapp, grupobobapp
• Em /users/bob/, as pastas têm permissões 750(leitura/gravação/executável para o proprietário, leitura/executável para o grupo, nenhuma para todos) e arquivos normais 640(leitura/gravação para o proprietário, leitura para o grupo, nenhuma para todos), arquivos executáveis 750​​(leitura/gravação/ executável para proprietário, lido/executável para grupo, nenhum para todos)
• /users/bob/myapp/logstem permissões 700 (leitura/gravação/executável para proprietário, nenhuma para grupo e nenhuma para todos os outros)

Nota 1: Para o aplicativo gráfico em execução bobappser exibido na bobsessão seria outro problema, mas existem muitas opções para permitir que boba sessão veja e interaja com bobappo aplicativo gráfico.

Nota 2: sudoseria usado caso você bobqueira iniciar myapp, pois precisa obter permissões temporárias para executar o aplicativo. sudoseria muito restrito e permitiria apenas bobiniciar o programa como bobappusuário.

Nota 3: Quando a aplicação ou o usuário cria novos arquivos e pastas, você precisa ter cuidado com as permissões padrão que serão herdadas quando os novos arquivos e pastas forem criados (várias opções, provavelmente eu usaria algo comoesse)

Answer 1

Como você resolveria isso em sistemas Linux?
Como o aplicativo é executado no contexto do usuário, as permissões de leitura e gravação são as mesmas.
Você pode definir permissões de diretório com Caclsou por meio da rotina do instalador.
Você provavelmente tornaria o diretório principal c:\Users\bob\myapplegível e gravável.
Herde essas permissões para todos os subdiretórios, exceto c:\Users\bob\myapp\logs.
Você mencionou sudona recompensa, então meu palpite é que você vê o mesmo problema. Você não pode aplicar restrições onde o aplicativo é executado no mesmo contexto. Portanto, você precisaria executar o aplicativo em um contexto de usuário diferente ou encontrar uma solução diferente para o logsdiretório. Você pode cancelar a definição de permissões, ler/gravar e definir as permissões novamente. Como o usuário é o proprietário do diretório quando o criou, você pode alterar as permissões a qualquer momento.

Sobre sua pergunta sobre o caminho do Windows: Existem caminhos protegidos como C:\Program Files\ou C:\Windows\que precisam de privilégios administrativos (e são de propriedade do TrustedInstaller). Portanto, é importante onde construir seus diretórios.

Editar:
Da atualização do PO referida sudo. Esta ferramenta é necessária para executar um programa como outro usuário, normalmente configurado para não precisar de senha para alterar o contexto. Pelo que eu sei, não há equivalente no Windows vanilla.
Você pode ver a discussãoaquisobre como obter prompts elevados, etc., mas principalmente eles exigem direitos administrativos e/ou exigem que você insira uma senha como runas.
Adicionalmente "Representar um cliente após autenticação"pode ​​ajudar, mas nunca usei e não posso dizer nada sobre isso.