1
0
mirror of https://github.com/samba-team/samba.git synced 2024-12-23 17:34:34 +03:00
samba-mirror/source4/rpc_server/winreg/rpc_winreg.c

416 lines
9.2 KiB
C
Raw Normal View History

/*
Unix SMB/CIFS implementation.
endpoint server for the winreg pipe
Copyright (C) Jelmer Vernooij 2004
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include "includes.h"
#include "rpc_server/common/common.h"
enum handle_types { HTYPE_REGVAL, HTYPE_REGKEY };
static void winreg_destroy_hive(struct dcesrv_connection *c, struct dcesrv_handle *h)
{
/* FIXME: Free ((struct registry_key *)h->data)->root->hive->reg_ctx */
}
static WERROR winreg_openhive (struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx, const char *hivename, struct policy_handle **outh)
{
struct registry_context *ctx;
struct dcesrv_handle *h;
WERROR error;
const char *conf = lp_parm_string(-1, "registry", hivename);
char *backend, *location;
if (!conf) {
return WERR_NOT_SUPPORTED;
}
backend = talloc_strdup(mem_ctx, conf);
location = strchr(backend, ':');
if (location) {
*location = '\0';
location++;
}
error = reg_open(&ctx, backend, location, NULL);
if(!W_ERROR_IS_OK(error)) return error;
h = dcesrv_handle_new(dce_call->conn, HTYPE_REGKEY);
h->data = ctx->hives[0]->root;
SMB_ASSERT(h->data);
h->destroy = winreg_destroy_hive;
*outh = &h->wire_handle;
return WERR_OK;
}
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
#define func_winreg_OpenHive(k,n) static WERROR winreg_Open ## k (struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx, struct winreg_Open ## k *r) \
{ \
return winreg_openhive (dce_call, mem_ctx, n, &r->out.handle);\
}
func_winreg_OpenHive(HKCR,"HKEY_CLASSES_ROOT")
func_winreg_OpenHive(HKCU,"HKEY_CURRENT_USER")
func_winreg_OpenHive(HKLM,"HKEY_LOCAL_MACHINE")
func_winreg_OpenHive(HKPD,"HKEY_PERFORMANCE_DATA")
func_winreg_OpenHive(HKU,"HKEY_USERS")
func_winreg_OpenHive(HKCC,"HKEY_CC")
func_winreg_OpenHive(HKDD,"HKEY_DD")
func_winreg_OpenHive(HKPT,"HKEY_PT")
func_winreg_OpenHive(HKPN,"HKEY_PN")
/*
winreg_CloseKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_CloseKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_CloseKey *r)
{
struct dcesrv_handle *h;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGKEY);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
DCESRV_CHECK_HANDLE(h);
dcesrv_handle_destroy(dce_call->conn, h);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_OK;
}
/*
winreg_CreateKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_CreateKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_CreateKey *r)
{
struct dcesrv_handle *h, *newh;
WERROR error;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGKEY);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
DCESRV_CHECK_HANDLE(h);
newh = dcesrv_handle_new(dce_call->conn, HTYPE_REGKEY);
error = reg_key_add_name(newh, (struct registry_key *)h->data, r->in.key.name,
r->in.access_mask,
r->in.sec_desc?r->in.sec_desc->sd:NULL,
(struct registry_key **)&newh->data);
if(W_ERROR_IS_OK(error)) {
r->out.handle = &newh->wire_handle;
} else {
dcesrv_handle_destroy(dce_call->conn, newh);
}
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return error;
}
/*
winreg_DeleteKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_DeleteKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_DeleteKey *r)
{
struct dcesrv_handle *h;
struct registry_key *key;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
WERROR result;
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGKEY);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
DCESRV_CHECK_HANDLE(h);
result = reg_open_key(mem_ctx, (struct registry_key *)h->data, r->in.key.name, &key);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
if (W_ERROR_IS_OK(result)) {
return reg_key_del(key);
}
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return result;
}
/*
winreg_DeleteValue
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_DeleteValue(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_DeleteValue *r)
{
struct dcesrv_handle *h;
struct registry_value *value;
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGVAL);
DCESRV_CHECK_HANDLE(h);
value = h->data;
/* FIXME */
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_EnumKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_EnumKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_EnumKey *r)
{
struct dcesrv_handle *h;
struct registry_key *key;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGKEY);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
DCESRV_CHECK_HANDLE(h);
key = h->data;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_EnumValue
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_EnumValue(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_EnumValue *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_FlushKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_FlushKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_FlushKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_GetKeySecurity
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_GetKeySecurity(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_GetKeySecurity *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_LoadKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_LoadKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_LoadKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_NotifyChangeKeyValue
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_NotifyChangeKeyValue(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_NotifyChangeKeyValue *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_OpenKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_OpenKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_OpenKey *r)
{
struct dcesrv_handle *h, *newh;
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
WERROR result;
h = dcesrv_handle_fetch(dce_call->conn, r->in.handle, HTYPE_REGKEY);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
DCESRV_CHECK_HANDLE(h);
newh = dcesrv_handle_new(dce_call->conn, HTYPE_REGKEY);
result = reg_open_key(newh, (struct registry_key *)h->data,
r->in.keyname.name, (struct registry_key **)&newh->data);
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
if (W_ERROR_IS_OK(result)) {
r->out.handle = &newh->wire_handle;
} else {
dcesrv_handle_destroy(dce_call->conn, newh);
}
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return result;
}
/*
winreg_QueryInfoKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_QueryInfoKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_QueryInfoKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_QueryValue
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_QueryValue(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_QueryValue *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_ReplaceKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_ReplaceKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_ReplaceKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_RestoreKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_RestoreKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_RestoreKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_SaveKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_SaveKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_SaveKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_SetKeySecurity
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_SetKeySecurity(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_SetKeySecurity *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_SetValue
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_SetValue(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_SetValue *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_UnLoadKey
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_UnLoadKey(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_UnLoadKey *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_InitiateSystemShutdown
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_InitiateSystemShutdown(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_InitiateSystemShutdown *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_AbortSystemShutdown
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_AbortSystemShutdown(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_AbortSystemShutdown *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_GetVersion
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_GetVersion(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_GetVersion *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_QueryMultipleValues
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_QueryMultipleValues(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_QueryMultipleValues *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_InitiateSystemShutdownEx
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_InitiateSystemShutdownEx(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_InitiateSystemShutdownEx *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_SaveKeyEx
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_SaveKeyEx(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_SaveKeyEx *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/*
winreg_QueryMultipleValues2
*/
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
static WERROR winreg_QueryMultipleValues2(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
struct winreg_QueryMultipleValues2 *r)
{
r464: a big improvement to the API for writing server-side RPC servers. Previously the server pipe code needed to return the RPC level status (nearly always "OK") and separately set the function call return using r->out.result. All the programmers writing servers (metze, jelmer and me) were often getting this wrong, by doing things like "return NT_STATUS_NO_MEMORY" which was really quite meaningless as there is no code like that at the dcerpc level. I have now modified pidl to generate the necessary boilerplate so that just returning the status you want from the function will work. So for a NTSTATUS function you return NT_STATUS_XXX and from a WERROR function you return WERR_XXX. If you really want to generate a DCERPC level fault rather than just a return value in your function then you should use the DCESRV_FAULT() macro which will correctly generate a fault for you. As a side effect, this also adds automatic type checking of all of our server side rpc functions, which was impossible with the old API. When I changed the API I found and fixed quite a few functions with the wrong type information, so this is definately useful. I have also changed the server side template generation to generate a DCERPC "operation range error" by default when you have not yet filled in a server side function. This allows us to correctly implement functions in any order in our rpc pipe servers and give the client the right information about the fault. (This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
2004-05-04 10:07:52 +04:00
return WERR_NOT_SUPPORTED;
}
/* include the generated boilerplate */
#include "librpc/gen_ndr/ndr_winreg_s.c"