[jcifs] Problems with implementing LsarLookupSids()

Michael B Allen mba2000 at ioplex.com
Fri Dec 10 23:24:10 GMT 2004

On Fri, 10 Dec 2004 11:48:25 +0100
Ralf Hartmann <Ralf.Hartmann at xsystem.de> wrote:

> Hello Mr. Allen,
> i want to use jarapac 0.3.7 to resolve SID's to user names. I have changed
> the IDL to support LsarLookupSids() (please refer the attachment). The IDL
> has been compiled with MIDL 0.5.1. The request looks fine in the network
> trace. Also the response from the W2K system looks OK. But the decoding of
> the network packet leads to a crash

Hi Ralf,

There is an important issue that needs to be understood when using midlc
Java stubs (at least at the moment). The MIDL language uses C constructs and
is expected to be used with the C language. In C when you have a struct that
contains a fixed size array or another embedded structure those members
constitute the memory of the parent structure. Consider the following:

struct foo {
	int i;
	int arr[10];

You can declare and use this like:

	struct foo foo;
	foo.arr[3] = 6;

So how do we map this to Java? We use a class like:

public class foo {
	int i;
	int[] arr;

If we declare and use this like we did the C example:

public static void main(String[] args) throws Exception {
	foo foo = new foo();
	foo.arr[3] = 6;

Whooops! That's going to generate a null pointer exception because in Java
we need to allocate an array. The same problem occurs with embedded structs.
If we have a C struct.

struct bar {
	int i;
	struct foo;

And use the analygous Java class like:

public static void main(String[] args) throws Exception {
	bar bar = new bar();
	bar.foo.arr[3] = 6;

This would throw null pointer exceptions all over the place. We really would
have to do:

public static void main(String[] args) throws Exception {
	bar bar = new bar();
	bar.foo = new foo();
	bar.foo.arr = new int[10];
	bar.foo.arr[3] = 6;

Ultimately the problem is that arrays and classes cannot be embedded in Java
as everything is by reference. In your particular case you have a struct

	typedef struct {
		unicode_string name;
		sid_t *sid;
	} lsa_TrustInformation;

The name member is an embedded struct that is initialized to null and thus
you get a null pointer exception when the stub references it. If it had been
a pointer you would be OK because the runtime will know to allocate such
object automatically.

To get around this problem, I have so far just preallocated objects and
arrays as necessary such as in 'handle.uuid = new rpc.uuid_t();' in

The proper solution may be to simply adjust the stubs to automatically
allocate these objects as necessary. I don't believe there is any
fundamental problem with doing that. I just didn't do it because I didn't
know for certain what the correct way to handle it was. Now however, I think
it's clear that these objects will need to be allocated automatically as
there may be [out] only parameters that have embedded arrays and structs in
decendant objects in which case there would be no way to pre-allocate them.
In fact LsarLookupSids is one such example because lsa_RefDomainList is
[out] only and is a parent of lsa_TrustInformation with an embedded
unicode_string. Also, even if a parameter is [in,out] it may be desirable to
pass null. I'll have to play with this and modify the Java stub emitter to
emit code to allocate these objects.

> name in lsa_TrustInformation  doesn't get initalized. I have changed this
> in the Java source.  But this leads to another crash in decoding the
> response.

Yeah, well you would have to fix it in the decoder too.

> Can you help me please? Maybe you have implemented LsarLookupSids in the
> IDL but not distributed it yet.

No. Other than some winreg functions 0.5.1 has all the latest IDL.

> Or you have a hint what is wrong with my IDL.

The IDL looks ok. It looks like you're going on the Samba4 IDL which is a
little differnt from MIDL IDL so I can't say it's right. I'll have to check

> Maybe the SID.java i have used for the testing is for interest of you. So
> i send it as an attachment.

Yes, that looks like what I wanted to do with that. I'll definately include

> Next i will try to implement NTQuerySecurityDesc as an addon to JCIFS. I
> need both (LsarLookupSids and NTQuerySecurityDesc) to display the file
> owner.

This is going to be a little bit of a problem. From looking at traces it
became apparent to me that security descriptors are not encoded in NDR. I
suspect that the [transmit_as] attribute is used to encode and decode those
fragments (which makes sense considering the same format appears in NT
Transact SMBs that operate on security descriptors). The emitter will need
to be adjusted to support this attribute. That change is very simple but it
will also then be necessary to write encoder/decoder functions to properly
code for security descriptors which is a little harder than copying some
MIDL from Samba4.


Greedo shoots first? Not in my Star Wars.

More information about the jcifs mailing list