psexec for Linux and svcctl.idl changes
Henrik Zagerholm
henke at mac.se
Sat Jul 1 15:09:15 GMT 2006
Good job Andrzej!
I've been looking for this a long time and I'm thrilled to test it out.
I'll give you some feedback as soon as I've tested it out on a couple
of systems.
Once again good work!
Cheers,
Henrik
1 jul 2006 kl. 01:26 skrev AH:
> Hello
>
>
> I am not a regular samba developer, but I wanted to have psexec
> equivalent, so I wrote it, it works but still need some development.
> I do not know if patches of such sizes (about 30k) are welcome on
> this list so I've put it on web page, with some description:
> http://eol.ovh.org/winexe/
> Comments welcome.
>
> I will describe what I have changed in svcctl.idl and my
> observations/propositions to new types.
> This patch do not make many changes in samba4 files, it just add
> one subdir (with program) and modify 2 files.
> In main.mk it adds line "+include winexe/config.mk" - nothing
> intersting.
> The main changes are in librpc/idl/svcctl.idl, diff at the end of e-
> mail.
> Changes in librpc/idl/svcctl.idl is just a dirty hack, because of
> lack of some idl types.
> What I have changed in svcctl.idl:
> 1. svcctl_OpenServiceW - quite clean patch
> a) Parameter ServiceName cannot be null, so ndr_push_*_ptr should
> not be generated by pidl, adding [ref] before parameter solves the
> problem
> b) function returns policy_handle* so I have added "[out,ref]
> policy_handle *handle".
> 2. svcctl_CreateServiceW - dirty patch
> a) Changed 'handle' to 'scmanager_handle' - I have reserved
> 'handle' to service handle, and it is more compatible with
> svcctl_OpenServiceW
> b) ServiceName - added [ref], as in point 1a
> c) binary_path - added [ref], as in point 1a (according to msdn it
> also cannot be null)
> d) TagId - it is used also as input (if null, windows do not fill
> *TagId), so I've changed it to "[in,out] uint32 *TagId"
> e) dependencies - (dirty part) - according to msdn it is a "Pointer
> to a double null-terminated array of null-separated names", and how
> it is
> encoded by idl:
> Sample, fragment of network packet with two dependencies
> (ahdep1,ahdep2):
> 0150 90 9b 09 00 1e
> 00 ................
> 0160 00 00 61 00 68 00 64 00 65 00 70 00 31 00 00 00 ..a.h.d.e.p.
> 1...
> 0170 61 00 68 00 64 00 65 00 70 00 32 00 00 00 00 00 a.h.d.e.p.
> 2.....
> 0180 00 00 1e 00 00 00
> So we have:
> - some ptr (4bytes) length of array (4bytes) - 90 9b 09 00
> - length of array in bytes (4 bytes) - 1e 00 00 00
> - "double null-terminated array of null-separated names" in utf16
> (0x1e bytes)- 61 00 68 00 64 00 65 00 70 00 31 00 00 00 61 00 68 00
> 64 00 65 00 70 00 32 00 00 00 00 00
> - alignment (2 bytes) - 00 00
> - again length of array in bytes (4 bytes) - 1e 00 00 00
> I haven't find this kind of type in idl, so I have dirty encoded it
> as:
> [in] [string,charset(UTF16)] uint16 *dependencies,
> [in] uint32 fix_len_dependencies,
> For null dependencies it works flawlessly :)
> f) password - similar story:
> after encryption (I do not know what algorithm is used, any
> guesses?) password is saved as array of bytes in format:
> -some ptr (4bytes),
> -length in bytes(4bytes),
> -array (length bytes),
> -again length in bytes (4bytes)
> I've made again a dirty hack:
> [in] [string,charset(UTF16)] uint16 *password,
> [in] uint32 fix_len_password,
> And again it works OK with null passwords.
> g) Added result:
> [out,ref] policy_handle *handle
>
> I hope it will be helpful to somebody.
>
> Andrzej Hajda
>
> And promised diff:
> ===================================================================
> --- librpc/idl/svcctl.idl (revision 16714)
> +++ librpc/idl/svcctl.idl (working copy)
> @@ -164,19 +164,22 @@
>
> /*****************/
> /* Function 0x0c */
> - WERROR svcctl_CreateServiceW([in,ref] policy_handle *handle,
> -
> [in] [string,charset(UTF16)] uint16 *ServiceName,
> + WERROR svcctl_CreateServiceW([in,ref] policy_handle
> *scmanager_handle,
> +
> [in,ref] [string,charset(UTF16)] uint16 *ServiceName,
> [in]
> [string,charset(UTF16)] uint16 *DisplayName,
> [in]
> uint32 desired_access,
> [in]
> uint32 type,
> [in]
> uint32 start_type,
> [in]
> uint32 error_control,
> -
> [in] [string,charset(UTF16)] uint16 *binary_path,
> +
> [in,ref] [string,charset(UTF16)] uint16 *binary_path,
> [in]
> [string,charset(UTF16)] uint16 *LoadOrderGroupKey,
> -
> [out] uint32 *TagId,
> +
> [in,out] uint32 *TagId,
> [in]
> [string,charset(UTF16)] uint16 *dependencies,
> +
> [in] uint32 fix_len_dependencies,
> [in]
> [string,charset(UTF16)] uint16 *service_start_name,
> -
> [in] [string,charset(UTF16)] uint16 *password);
> +
> [in] [string,charset(UTF16)] uint16 *password,
> +
> [in] uint32 fix_len_password,
> +
> [out,ref] policy_handle *handle);
>
> /*****************/
> /* Function 0x0d */
> @@ -210,8 +213,9 @@
> /*****************/
> /* Function 0x10 */
> WERROR svcctl_OpenServiceW([in,ref] policy_handle
> *scmanager_handle,
> - [in]
> [string,charset(UTF16)] uint16 *ServiceName,
> - [in]
> uint32 access_mask);
> + [in,ref]
> [string,charset(UTF16)] uint16 *ServiceName,
> + [in]
> uint32 access_mask,
> + [out,ref]
> policy_handle *handle);
>
> /*****************/
> /* Function 0x11 */
> ===================================================================
>
>
More information about the samba-technical
mailing list