strano errore di autorizzazione che coinvolge i file ssh, Cygwin, Windows 7 e .sh

Sono nuovo su Cygwin, ssh e scherzo con i permessi dei file e ho un problema. Sul computer WORKER1, sto tentando di accedere a ssh nel computer WORKER2 e quindi eseguendo un file .sh su WORKER1 da lì. Da quello che posso dire dall'output di seguito, ls -l mostra che dovrebbe esserci l'autorizzazione per fare tutto (so che quelle sono cattive autorizzazioni da avere, ma stavo impazzendo cercando di capire perché stavo ottenendo questo errore di autorizzazione) .

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

Entrambi i computer eseguono Windows 7 a 64 bit e su ciascuno eseguo l'ultima versione di Cygwin e OpenSSH. Lo sshd in esecuzione su WORKER2 è anche quello di Cygwin. Durante l'installazione di sshd, l'unico modo in cui sono riuscito a farlo funzionare correttamente era rispondere "no" per privilegiare la separazione e "sì" all'installazione come servizio durante l'esecuzione di ssh-host-config. Sto usando l'autenticazione RSA a chiave pubblica. Ho provato a montare // WORKER1 / Users / Public / pMatlab / come unità di rete e accedervi in ​​quel modo, ma neanche questo mi ha aiutato. Qualche idea su cosa potrebbe andare storto? Grazie!

EDIT: ho dimenticato di menzionare che le mie impostazioni di condivisione della rete in Windows sono impostate per consentire tutto ciò che posso vedere. Inoltre, la mia cartella pubblica e le cartelle al suo interno sembrano essere tutte di sola lettura (nel menu di scelta rapida-> Proprietà), anche se i file al suo interno non lo sono. Il tentativo di modificare questa opzione nel menu Proprietà non fa nulla: quando spengo la sola lettura è di nuovo attivo quando riapro il menu Proprietà. Ho provato a cambiarlo eseguendo attrib -r C: \ Users \ Public in cmd.exe ma neanche quello ha fatto nulla.

Infine, non ricevo un errore di autorizzazione negata quando eseguo il file .sh localmente, quando provo ad accedervi dalla GUI di Windows sul computer WORKER2 o quando ssh da WORKER2 a se stesso e quindi provo ad accedervi. L'errore di autorizzazione appare solo quando ssh da WORKER1 a WORKER2 e quindi provo ad accedere al file su WORKER1 da lì.

Modifica finale: problema risolto. Si è scoperto che la cartella era crittografata! Non ho idea del perché. È così che è uscito dal file zip per qualche motivo.

Benvenuti nel meraviglioso nuovo mondo Unix del 1989!

Quelle simpatiche persone di TRUSIX hanno - proprio quest'anno - definito un'estensione del lscomando per indicare visivamente quando le rwxrwxrwxinformazioni sui permessi non sono in realtà l'intera storia. Tale estensione è un +carattere che segue i flag di autorizzazione. Come puoi vedere, il tuo lsoutput ha +caratteri ovunque. Ciò significa che i tuoi file hanno queste cose della lista di controllo degli accessi discrezionali di nuova concezione di cui le persone di TRUSIX sono così entusiaste. Pertanto, l'accesso ai file non è necessariamente quello che puoi dedurre dai soli nove flag di autorizzazione.

Per compensare queste limitazioni degli strumenti Unix vecchio stile di fronte ai nuovi ACL di stile, le persone di TRUSIX hanno anche escogitato un paio di nuovi comandi getacle setacl. Il primo è usato per guardare quegli ACL. Sento mormorii che le persone potrebbero preferire getfacle setfaclcome nomi. E c'è una voce in giro che la versione 3 / OS 3 di Microsoft e IBM che si trova sul tavolo da disegno potrebbe alla fine finire con i comandi nominati caclse xcaclsper guardare gli ACL che saranno persino migliori rispetto getfaclal loro sistema operativo "New Technology", perché " Non li presenterò attraverso un obiettivo Unix a 3 bit, ma piuttosto come sono realmente in tutti i loro diritti standard e specifici drctpoxfew sia per l'account che per-machine-name gloria.

Questa idea è destinata a prendere piede come un incendio, nel mondo Unix di cui tutti finiranno sicuramente una parte negli anni '90. È molto probabile che tra 20 anni nove bit di autorizzazioni sembreranno vecchio stile e passé, gli ACL saranno la norma e persino i fuddy-duddies che guardano ancora nove flag di permessi ne saranno a conoscenza . ☺

Ulteriori letture

• Craig Rubin (1989-08-18). Razionale per la selezione delle funzioni dell'elenco di controllo di accesso per il sistema Unix . NCSC-TG-020-A. Pubblicazione DIANE. ISBN 9780788105548.
• Microsoft corporation (2008-05-08). L'utente non può accedere a un file o una cartella ma dovrebbe avere l'autorizzazione . TechNet.