draft eventlog registry patch for review

[Brian Moran]

The samba-internal eventlog reading/writing code will need certain registry values, and will need to run for certain housekeeping operations (e.g. trimming logs to the registry-specified sizes, etc.), so it's probably a good idea to have a reasonable token around just for these cases. In the "external writer to the eventlog TDB" case, the process using the TDB code is going to have to have appropriate rights to access the TDB itself, absent any other type of mechanism.

 
________________________________

From: Gerald (Jerry) Carter [mailto:jerry at samba.org]
Sent: Wed 8/31/2005 12:43 PM
To: Brian Moran; Marcin Porwit
Cc: samba-technical at samba.org
Subject: Re: draft eventlog registry patch for review



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerald (Jerry) Carter wrote:
| Hey guys,
|
| Here's what I'm thinking for the eventlog code.
| The virtual eventlog registry paths are still
| handled by reg_eventlog.c.  The changes are
| to clean up the registry keys and values
| to regdb_fetch/store_XXX().
|
| I have not finished updateing the Eventlog
| rpc code to retreiving these values.  I'll
| finish up that tomorrow.  This is just basically
| for early review.

Here's another revision against trunk
http://samba.org/~jerry/patches/eventlog_registry_r9822_v2.patch

Some of the code will go away once the extra eventlog
smb.conf hook are removed.  Notably the changes to
control_eventlog_hook().

The main changes here are the move to regkey_open_internal()
which allows us to open a path and get REGISTRY_KEY*.  Which
can then be used in regkey_{fetch,store}_values().
Thus giving us a common API for storing configuration
information in the virtual registry.  Since this sits
on top of the REGISTRY_OPS* layer, it means the caller
doesn't have to worry about how or where the data is
actually stored.

Here's the general idea (taken from control_eventlog_hook()):

/* the general idea is to internally open the registry
        key and retrieve the values.  That way we can continue
        to use the same fetch/store api that we use in
        srv_reg_nt.c */

pstr_sprintf( path, "%s/%s", KEY_EVENTLOG, elogname );
wresult = regkey_open_internal( &keyinfo, path, token, REG_KEY_READ );

if ( !W_ERROR_IS_OK( wresult ) ) {
        ...
}

if ( !(values = TALLOC_ZERO_P( keyinfo, REGVAL_CTR )) ) {
        ....
}

fetch_reg_values( keyinfo, values );

if ( (val = regval_ctr_getvalue( values, "Retention" )) != NULL )
        uiRetention = IVAL( regval_data_p(val), 0 );

if ( (val = regval_ctr_getvalue( values, "MaxSize" )) != NULL )
        uiMaxSize = IVAL( regval_data_p(val), 0 );

TALLOC_FREE( keyinfo );


The main problem with this patch is the control_eventlog_hook()
now requiring that you pass in an NT_USER_TOKEN* for the
access checks necessary in regkey_open_internal().  The
only place the control_eventlog_hook() code gets invoked is
in init_registry_data(), but this poses a problem since
we don't have a valid user token then.  But I could
just create a token for root (which would be similar
to opening a key under the context of LOCAL_SYSTEM
on Windows).





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFDFd4XIR7qMdg1EfYRAu6MAJireGSdsyIFedxMhTiUs68Ix4xMAKCPykX9
F571M1whVPYf2e9GPn02lQ==
=2dwA
-----END PGP SIGNATURE-----