Perché l'attributo di sola lettura è impostato (a volte) per i file creati dal mio servizio?

Question

NOTA: questa è una riscrittura completa di questa domanda. In precedenza avevo confuso alcuni problemi ACL con il problema che sto cacciando, motivo per cui probabilmente non c'erano risposte.

Ho un servizio di Windows che utilizza le routine standard di apertura / chiusura / scrittura per scrivere un file di registro (legge cose da una pipe e le inserisce nel registro). Un nuovo file di registro viene aperto ogni giorno a mezzanotte. Il sistema è Windows XP Embedded.

Il servizio viene eseguito come servizio di sistema locale (CreateService con NULL per l'utente).

All'avvio iniziale del servizio, crea un file di registro e lo scrive senza problemi. A questo punto è tutto a posto e puoi riavviare il servizio (o il computer) senza problemi.

Tuttavia, a mezzanotte (quando il giorno cambia), il servizio crea un nuovo file di registro e vi scrive. La cosa divertente è che questo nuovo file di registro ha il flag 'sola lettura' impostato. Questo è un problema perché se il servizio (o il computer) viene riavviato, il servizio non può più aprire il file per la scrittura.

Ecco le informazioni rilevanti dal sistema con il problema già accaduto:

 Directory of C:\bbbaudit

09/16/2009  12:00 AM    <DIR>          .
09/16/2009  12:00 AM    <DIR>          ..
09/16/2009  12:00 AM               437 AU090915.ADX
09/16/2009  12:00 AM                62 AU090916.ADX

attrib c:\bbbaudit\*
A          C:\bbbaudit\AU090915.ADX <-- old log file (before midnight)
A    R     C:\bbbaudit\AU090916.ADX <-- new log file (after midnight)

cacls output:
C:\ BUILTIN\Administrators:(OI)(CI)F 
    NT AUTHORITY\SYSTEM:(OI)(CI)F 
    CREATOR OWNER:(OI)(CI)(IO)F 
    BUILTIN\Users:(OI)(CI)R 
    BUILTIN\Users:(CI)(special access:)
                      FILE_APPEND_DATA

    BUILTIN\Users:(CI)(IO)(special access:)
                          FILE_WRITE_DATA

    Everyone:R 

C:\bbbaudit BUILTIN\Administrators:(OI)(CI)F 
            NT AUTHORITY\SYSTEM:(OI)(CI)F 
            CFN3\Administrator:F 
            CREATOR OWNER:(OI)(CI)(IO)F 

Ecco il codice che uso per aprire / creare i file di registro:

static int open_or_create_file(char *fname, bool &alreadyExists)
{
  int fdes;

  // try to create new file, fail if it already exists
  alreadyExists = false;
  fdes = open(fname, O_WRONLY | O_APPEND | O_CREAT | O_EXCL);
  if (fdes < 0)
  {
    // try to open existing, don't create new file
    alreadyExists = true;
    fdes = open(fname, O_WRONLY | O_APPEND);
  }

  return fdes;
}

Ho davvero problemi a capire come il file sta ottenendo quel flag di sola lettura su di esso. Chiunque possa darmi un indizio o una direzione, lo apprezzerei molto.

Il compilatore è VC 6 (Sì, lo so, è così obsoleto che non è divertente. Fino a quando non ti rendi conto che siamo appena passati a XPE da NT 3.51).

Answer 1

L'implementazione Microsoft di open () ha un terzo argomento facoltativo 'pmode', che deve essere presente quando il secondo argomento 'oflag' include il flag O_CREAT. L'argomento pmode specifica le impostazioni di autorizzazione del file, che vengono impostate quando il nuovo file viene chiuso per la prima volta. In genere si passa S_IREAD | S_IWRITE per pmode, risultante in un normale file di lettura / scrittura.

Nel tuo caso hai specificato O_CREAT ma hai omesso il terzo argomento, quindi open () ha usato qualunque valore si trovasse nello stack nella posizione del terzo argomento. Il valore di S_IWRITE è 0x0080, quindi se il valore nella posizione del terzo argomento avesse il bit 7 libero, si tradurrebbe in un file di sola lettura. Il fatto che tu abbia ottenuto un file di sola lettura solo qualche volta, è coerente con il junk dello stack passato come terzo argomento.

Di seguito è riportato il collegamento per la documentazione di Visual Studio 2010 per open (). Questo aspetto del comportamento della funzione non è cambiato da VC 6.

http://msdn.microsoft.com/en-us/library/ z0kc8e3z.aspx

Answer 2

Bene, non ho idea di quale sia il problema di fondo con le API 'aperte' in questo caso. Per "risolvere" il problema, ho finito col passare all'utilizzo delle API Win32 per la gestione dei file (CreateFile, WriteFile, CloseHandle).