estranho erro de permissão envolvendo arquivos ssh, Cygwin, Windows 7 e .sh

estranho erro de permissão envolvendo arquivos ssh, Cygwin, Windows 7 e .sh

Sou novo no Cygwin, ssh, estou mexendo nas permissões de arquivo e estou com um problema. No computador WORKER1, estou tentando fazer ssh no computador WORKER2 e, em seguida, executar um arquivo .sh no WORKER1 a partir daí. Pelo que posso dizer na saída abaixo, ls -l mostra que deve haver permissão para fazer tudo (eu sei que essas permissões são ruins, mas eu estava enlouquecendo tentando descobrir por que estava recebendo esse erro de permissão) .

root@Worker1 ~
$ ssh WORKER2
Last login: Tue Jan 31 10:51:54 2012 from worker1

root@Worker2 ~
$ cd //WORKER1/Users/Public/pMatlab/MatlabMPI/Examples/MatMPI

root@Worker2 //WORKER1/Users/Public/pMatlab/MatlabMPI/Examples/MatMPI
$ sh Dos_Commands.WORKER2.1.sh
sh: Dos_Commands.WORKER2.1.sh: Permission denied

root@Worker2 //WORKER1/Users/Public/pMatlab/MatlabMPI/Examples/MatMPI
$ ls -l
total 28
-rwxrwxrwx+ 1 Administrators None   2 Jan 31 11:01 Dos_Commands.WORKER1.0
-rwxrwxrwx+ 1 Administrators None 127 Jan 31 11:01 Dos_Commands.WORKER2.1
-rwxrwxrwx+ 1 Administrators None 250 Jan 31 11:01 Dos_Commands.bat
-rwxrwxrwx+ 1 Administrators None 636 Jan 31 11:01 MPI_COMM_WORLD.mat
-rwxrwxrwx+ 1 Administrators None  97 Jan 31 11:01 MatMPIdefs1.m
-rwxrwxrwx+ 1 Administrators None 199 Jan 31 11:01 p0_p0_t10000_buffer.ma
-rwxrwxrwx+ 1 Administrators None 199 Jan 31 11:01 p0_p1_t10000_buffer.ma
-rwxrwxrwx+ 1 Administrators None   0 Jan 31 11:01 p0_p1_t10000_lock.mat

Ambos os computadores estão executando o Windows 7 de 64 bits e estou executando a versão mais recente do Cygwin e do OpenSSH em cada um. O sshd rodando no WORKER2 também é o do Cygwin. Ao instalar o sshd, a única maneira de fazê-lo funcionar corretamente foi responder 'não' à separação de privilégios e 'sim' à instalação como um serviço ao executar o ssh-host-config. Estou usando autenticação RSA de chave pública. Tentei montar //WORKER1/Users/Public/pMatlab/ como uma unidade de rede e acessá-lo dessa forma, mas isso também não ajudou. Alguma idéia do que pode estar errado? Obrigado!

EDITAR: esqueci de mencionar que minhas configurações de compartilhamento de rede no Windows estão definidas para permitir tudo o que posso ver. Além disso, minha pasta Pública e as pastas dentro dela parecem estar configuradas como somente leitura (no clique com o botão direito-> menu Propriedades), embora os arquivos dentro dela não estejam. Tentar alterar isso no menu Propriedades não faz nada - quando desativo o modo somente leitura, ele volta a ser ativado quando reabro o menu Propriedades. Tentei mudar isso executando attrib -r C:\Users\Public em cmd.exe, mas também não adiantou nada.

Por fim, não recebo um erro de permissão negada ao executar o arquivo .sh localmente, quando tento acessá-lo a partir da GUI do Windows no computador WORKER2 ou quando faço ssh do WORKER2 para si mesmo e tento acessá-lo. O erro de permissão só aparece quando eu ssh do WORKER1 para o WORKER2 e tento acessar o arquivo no WORKER1 a partir daí.

Edição final: problema resolvido. Acontece que a pasta estava criptografada! Não faço ideia do porquê. Foi assim que saiu do arquivo zip por algum motivo.

Responder1

Bem-vindo ao maravilhoso novo mundo Unix de 1989!

Essas simpáticas pessoas da TRUSIX definiram - ainda este ano - uma extensão do lscomando para indicar visualmente quando as rwxrwxrwxinformações de permissão não são realmente a história toda. Essa extensão é um +caractere após os sinalizadores de permissão. Como você pode ver, sua lssaída possui +caracteres espalhados por todo o lugar. Isso significa que seus arquivos têm essas novidadeslista de controle de acesso discricionáriocoisas que deixam o pessoal da TRUSIX tão entusiasmado. Como tal, o seu acesso aos arquivos énãonecessariamente o que você pode deduzir apenas dos nove sinalizadores de permissão.

Para compensar essas limitações das ferramentas Unix antigas em face das ACLs de novo estilo, o pessoal da TRUSIX também criou alguns comandos novos, getacle setacl. O primeiro é usado para observar essas ACLs. Ouço murmúrios que as pessoas talvez prefiramgetfaclesetfaclcomo nomes. E há um boato de que o OS/2 versão 3 da Microsoft e da IBM que está na prancheta pode eventualmente acabar com comandos nomeados caclse xcaclspara olhar para ACLs que serãomelhor aindado que getfaclem seu sistema operacional de "Nova Tecnologia", porque eles não os apresentarão através de lentes Unix de 3 bits, mas sim como eles realmente são em todos os seusdireitos padrão e específicos drctpoxfewambas as contase-glória do nome da máquina.

Essa ideia certamente se espalhará como um incêndio no mundo Unix, do qual todos certamente farão parte na década de 1990. É muito provável que daqui a 20 anos nove bits de permissões pareçam ultrapassados ​​e ultrapassados, as ACLs sejam a norma eaté mesmo os idiotas que ainda olham para nove sinalizadores de permissão saberão sobre eles. ☺

Leitura adicional

informação relacionada