[C#] Bloccare un computer con WinXP32

[uReverendo]

Devo scrivere un programma che una volta eseguito, magari all'avvio del sistema, blocchi il computer.
In pratica l'utente interagirà solo con il mio programma. Se si verificano delle condizioni il programma sbloccherà il computer e permetterà all'utente di utilizzarlo. Se durante l'utilizzo queste condizioni vengono meno, il computer sarà nuovamente bloccato.

Per comodità e per mancanza di tempo, il programma per verificare le condizioni intendo scriverlo in C# e quindi escluderei (per ora) un GINA, a meno che non mi diciate come far interagire il mio GINA con C#.

Mi interessa soprattutto capire a livello teorico come muovermi e come organizzare il lavoro inquanto sono quasi completamente a digiuno sull'argomento.
Qualche consiglio?

[tomminno]

Stando a questo documento direi che puoi usare solo il buon caro vecchio C/C++ per personalizzare il logon:
http://support.microsoft.com/default.aspx?scid=kb;en-us;841927&Product=NETFrame
Generalmente si personalizza GINA.dll per procedue di accesso custom es. lettori di impronte digitali o token USB.

In ogni caso una volta effettuato il logon, per bloccare l'utente, dovresti richiamare LockWorkStation, da un applicativo che non sia un servizio, ma che può essere tranquillamente un applicativo C#.

[uReverendo]

Utilizzare LockWorkStation è la soluzione più razionale, ma purtroppo implica la scrittura di un GINA.

Infatti dopo aver bloccato il compuer, credo che l'unico modo per sbloccarlo al verificarsi delle condizioni sia far restituire WLX_SAS_ACTION_UNLOCK_WKSTA alla funzione WlxWkstaLockedSAS di GINA. Quindi la verifica delle condizioni deve avvenire in quella funzione di GINA percui non posso usare C#.

Preferisco usare C# inquanto devo collegarmi ad un'istanza di SQLSERVER 2005 EXPRESS ed eseguire strored procedure con parametri (sia di input che di output). Utilizzando il C/C++ non saprei da dove iniziare.

Esiste un modo per ottenere un risultato simile a LockWorkStation ma che permetta alla mia applicazione C# di gestire il tutto?

In pratica quando il computer è bloccato l'utente vedrà solo la mia interfaccia.

[fero86]

be', se il problema del C++ é che non sai come accedere al database posso indicarti OLE DB: http://msdn.microsoft.com/en-us/library/ms722784(VS.85).aspx

altrimenti non potresti sviluppare parte dell'applicazione in C# e parte in C++? in C# é possibile importare funzioni dalle DLL native, oppure puoi anche sfruttare l'interoperabilitá di COM ma in questo caso é piu difficile, penso che a te basti una DLL nativa che esporta qualche funzione.

[uReverendo]

Leggendo la prima riga del link mi è sorto un dubbio:
OLE DB is a set of COM-based interfaces that expose data from a variety of sources.
Essendo OLE DB un set di interfacce COM posso utilizzarle in GINA?
Stando al documento linkatomi da tomminno no. Non vorrei perdere tempo a studiarmi qualche cosa che non posso utilizzare. Hai info a riguardo?

altrimenti non potresti sviluppare parte dell'applicazione in C# e parte in C++?
Se devo scrivere un GINA no, devo fare tutto in C/C++.
Se riesco a fare a meno del GINA certo che si... il punto è come bloccare il computer senza l'ausilio di LockWorkStation e GINA.

[fero86]

Leggendo la prima riga del link mi è sorto un dubbio:

Essendo OLE DB un set di interfacce COM posso utilizzarle in GINA?
Stando al documento linkatomi da tomminno no. Non vorrei perdere tempo a studiarmi qualche cosa che non posso utilizzare. Hai info a riguardo? non mi ero accorto di questo problema perché non avevo letto il link di tomminno; non ho altre informazioni a riguardo ma il fatto é che se anche ipoteticamente OLE DB funzionasse senza problemi quando usato da un GINA (che é possibilissimo) potrebbe smettere di funzionare non appena il sistema subisce un aggiornamento oppure potrebbe non funzionare affatto su versioni future del sistema operativo.
come spiegato eloquentemente dal link, i frameworks elencati non sono stati progettati per essere usati in "core processes" del sistema operativo; quando Microsoft modifica l'architettura di quelle parti del sistema quei frameworks probabilmente non li testa neanche.

quindi direi che quello che puoi fare é sviluppare una DLL GINA che apre una named pipe e tramite di essa comunica con un servizio che accede al database; il servizio puoi scriverlo interamente in C# (vedi http://msdn.microsoft.com/en-us/library/system.serviceprocess.aspx). come meccanismo di IPC ti consiglio la named pipe perché secondo me é il piu adatto dovendo utilizzare solo API C Win32 nude e crude, inoltre ti consiglio di usare un GUID come nome della named pipe.


Se devo scrivere un GINA no, devo fare tutto in C/C++.
Se riesco a fare a meno del GINA certo che si... il punto è come bloccare il computer senza l'ausilio di LockWorkStation e GINA. é possibilissimo ma qualunque soluzione ti venga in mente fará sicuramente accapponare la pelle; da quanto ho capito quello che devi fare tu é proprio di scrivere un GINA, peró non é escluso che tu possa sviluppare l'applicazione in piu parti comunicanti (vedi sopra).

[uReverendo]

quindi direi che quello che puoi fare é sviluppare una DLL GINA che apre una named pipe e tramite di essa comunica con un servizio che accede al database; il servizio puoi scriverlo interamente in C# (vedi http://msdn.microsoft.com/en-us/library/system.serviceprocess.aspx). come meccanismo di IPC ti consiglio la named pipe perché secondo me é il piu adatto dovendo utilizzare solo API C Win32 nude e crude, inoltre ti consiglio di usare un GUID come nome della named pipe.
Se implementerò un GINA seguirò il tuo consiglio.

Nel frattempo ho trovato una soluzione alternativa molto semplice:
- creo un nuovo desktop (CreateDesktop());
- eseguo sul desktop appena creato il mio programma (CreateProcess());
- attivo il nuovo desktop (SwitchDesktop()).

Tutto qui, tre API richiamabili tramite interop che riproducono il comportamento che voglio, permettere all'utente di interagire solo con il mio programma.

Dici che fa accapponare la pelle come soluzione?

[fero86]

Dici che fa accapponare la pelle come soluzione? si: é sufficiente che l'utente esegua una chiamata SwitchDesktop in qualche modo, per esempio tramite un programma registrato su un CD con Autorun oppure se il programma é un programma "a tempo" messo in esecuzione dall'utente prima che la workstation venisse bloccata.

una soluzione potrebbe essere quella di modificare la DACL del desktop iniziale ("Default") e togliere all'utente il permesso necessario per fare lo switch, ma resta il fatto che l'utente é proprietario del desktop di default, e il proprietario di un oggetto puó sempre cambiare i permessi dell'oggetto.

un'altra soluzione orripilante sarebbe invece quella di installare un low level hook sia per il mouse che per la tastiera che non faccia altro che restituire 1 senza chiamare CallNextHookEx; chiaramente fa schifo anche questa ma perlomeno in questo caso, visto che i debug hook non possono intercettare i low level hooks, non riesco a trovare alcuna scappatoia ammettendo che il tuo programma venga avviato prima di ogni altro possibile programma messo in esecuzione dall'utente.

comunque la soluzione migliore é sempre quella del GINA.

[uReverendo]

Grazie mille, sei stato molto chiaro.

Scriverò un GINA.