CVS update: samba/source/include

[Elrond]

On Thu, May 04, 2000 at 12:41:23PM +1000, Luke Kenneth Casson Leighton wrote:
> On Thu, 4 May 2000, Elrond wrote:
> 
> > 
> > Date:	Thursday May 4, 2000 @ 3:23
> > Author:	elrond
> > 
> > Update of /data/cvs/samba/source/include
> > In directory samba:/tmp/cvs-serv2336/include
> > 
> > Modified Files:
> >       Tag: SAMBA_TNG
> > 	proto.h rpc_client_proto.h rpc_lsa.h rpc_parse_proto.h 
> > Log Message:
> > "Wasted" this morning and last evening with researching:
> > 
> > Added lsa_enum_privs, client and server-side. This is a
> > list of stuff like SeMachineAccountPrivilege and some
> > sequential number, that starts with 2 and ends with 24.
> > Anyone any idea, what it is good for?
> > I was a little surprised, that one could do "enumprivs"
> > anonymously.
> > 
> > Also added lsa_priv_info, but only client-side, and the
> > rpcclient-command "privinfo" was just an attempt, I later
> > added better support directly in enumprivs (try
> > "enumprivs -i").
> > 
> > lsa_priv_info also has an (unaligned!) uint16 in its
> > response, that doesn't make any sense to me: For some
> > privilges it is 0x0, for others 0x407. (It's listed in
> > parenthesis after the description in enumprivs -i)
> 
> then that means that it is _just_ alignment padding, if it changes
> erratically.

I first thought, it was alignment too.
I decided for the uint16 after a _long_ time and looking at
a bunch of hexdumps. It was the only possibility, I could
see.

The important example:
Hexdump:
	00 00 00 00 00 00 00 00 60 00 00 C0
Parse:
	0000 ptr_info: 00000000
	(no info, no UNISTR2)
	0004 unknown: 0000
	0008 status: C0000060 (No such privilege)

It would be nice, if you could take a look at it.
Do:
	rpcclient -S nt-box -U % -d 10 -l log
		enumprivs -i
		privinfo nonexistentpriv

In the log look for lsa_io_r_priv_info, above the
parser-debug is a complete hexdump of the to-be-parsed-data
(entitled with "body"-something)

I'm quite sure, that there is an unaligned uint16, and its
contents is highly reproducable.

> the only way to tell properly is to have access to a
> non-intel-byte-order-compatible nt system (such as Sun's AS/U cascade
> product, or HP's AS/U product).

Yup, we realy need access to something like that...
(No, I don't have any access to those.)

    Elrond