2008-10-06 14 views
6

Ho sviluppato un'applicazione Windows che utilizza memoria condivisa --- vale a dire --- file mappati in memoria per la comunicazione tra processi. Ho un servizio di Windows che fa un po 'di elaborazione e scrive periodicamente i dati nel file mappato in memoria. Ho un'applicazione Windows separata che legge dal file mappato in memoria e visualizza le informazioni. L'applicazione funziona come previsto su Windows XP, XP Pro e Server 2003, ma NON su Vista.Autorizzazioni di accesso alla memoria condivisa su Windows

Posso vedere che i dati scritti nel file mappato in memoria stanno accadendo correttamente dal servizio Windows perché posso aprire il file con un editor di testo e vedere i messaggi memorizzati, ma l'applicazione "consumer" non può leggere dal file. Una cosa interessante da notare qui è che se chiudo l'applicazione consumer e la riavvio, consuma i messaggi che sono stati precedentemente scritti nel file mappato in memoria.

Inoltre, un'altra cosa strana è che ottengo lo stesso comportamento quando mi collego all'host di Windows utilizzando Remote Desktop e invoco/utilizzo l'applicazione consumer tramite desktop remoto. Tuttavia, se invoco Desktop remoto e mi connetto alla sessione della console dell'host di destinazione con il seguente comando: mstsc -v:servername /F -console, tutto funziona perfettamente.

Ecco perché penso che il problema sia relativo alle autorizzazioni. Qualcuno può commentare questo?

EDIT:

L'ACL che sto usando per creare il file di memoria mappata e gli oggetti mutex che sychronize accesso è la seguente:

TCHAR * szSD = TEXT("D:") 
       TEXT("(A;;RPWPCCDCLCSWRCWDWOGAFA;;;S-1-1-0)") 
       TEXT("(A;;GA;;;BG)") 
       TEXT("(A;;GA;;;AN)") 
       TEXT("(A;;GA;;;AU)") 
       TEXT("(A;;GA;;;LS)") 
       TEXT("(A;;GA;;;RD)") 
       TEXT("(A;;GA;;;WD)") 
       TEXT("(A;;GA;;;BA)"); 

Penso che questo possa essere parte del problema .

risposta

0

Hai provato a spostare il file in una posizione diversa. Prova a metterlo nella cartella "Documenti condivisi", questa sembra essere la cartella più accessibile in Vista.

+0

I documenti condivisi sono una posizione altamente insicura per i file relativi a IPC: non farlo. –

1

Con quale accesso si sta aprendo la sezione della memoria condivisa? Prova con FILE_MAP_ALL_ACCESS e scendi. Assicurati inoltre di non avere una condizione di competizione tra produttore e consumatori - quale crea la memoria condivisa? Assicurati che sia stato creato prima che l'altro cerchi di aprirlo. Un metodo consiste nel creare la sezione nel genitore prima di avviare il processo figlio - se si sta utilizzando un'architettura genitore/figlio.

Per poter accedere alla memoria condivisa, è possibile che sia necessario eseguire il backup su Vista per il bambino. Potrebbe anche essere correlato alla sessione della finestra che stai utilizzando. I servizi vengono eseguiti nella sessione 0 (credo) mentre altre app (soprattutto se si accede tramite desktop remoto) possono essere eseguite in un'altra sessione.

+0

Quindi sto utilizzando FILE_MAP_ALL_ACCESS per mappare la memoria condivisa e ho progettato il codice in modo che non importi chi crea prima la memoria condivisa. Ma il tuo suggerimento sulla sessione è interessante. Vedrò questo. –

6

così ho trovato la soluzione al mio problema:

In Windows XP, tutti gli oggetti di nome del kernel, come mutex, semaforo e gli oggetti mappati in memoria vengono memorizzati nello stesso spazio dei nomi. Quindi, quando diversi processi in diverse sessioni utente fanno riferimento a un particolare oggetto usando il suo nome, ottengono un handle per quell'oggetto. Tuttavia, come precauzione di sicurezza, i servizi terminal di Windows creano uno spazio dei nomi separato per gli oggetti del kernel a cui fanno riferimento i processi avviati nella sua sessione. Anche Windows Vista ha questo comportamento integrato, ecco perché la mia app non ha funzionato correttamente su Vista. Per elaborare, ho un servizio di Windows che viene eseguito nella sessione nulla e un'applicazione che viene eseguita in una sessione utente, quindi i miei oggetti con nome sono stati creati in spazi dei nomi separati.

La soluzione rapida per questo problema era di utilizzare lo spazio dei nomi Globale anteponendo "Globale \" a ciascun nome di oggetto del kernel che ho usato e che ha fatto il trucco.

+0

Probabilmente hai creato un buco di sicurezza sul tuo sistema. –

+1

Beh, ci sono pensieri contrastanti su quello. Vi sono momenti in cui si desidera fornire a un servizio diritti e capacità più elevati (ad esempio Sistema locale) rispetto a un'applicazione utente che deve essere in grado di interfacciarsi con quel servizio. È possibile che tu stia abilitando la sicurezza dando solo il servizio e non l'app a tutti gli accessi. Tuttavia è possibile visualizzare il fatto che il servizio esiste come potenziale buco di sicurezza. Ma non sono d'accordo. – Dan

3

Il prefisso "Global \" potrebbe non funzionare sulla memoria condivisa. Vedi "Impact of Session 0 Isolation on Services and Drivers in Windows Vista" per la soluzione.

+2

Questo documento convalida le mie soluzioni ... afferma "Il modo corretto per sincronizzare le applicazioni utente con un servizio è di usare esplicitamente il prefisso Global \". –