GSS IOV flags

Luke Howard lukeh at padl.com
Wed Dec 17 06:17:06 EST 2008


Hi Metze,

> #define SECBUFFER_EMPTY 0   // Undefined, replaced by provider
> see http://msdn.microsoft.com/en-us/library/aa380533(VS.85).aspx
> and http://technet.microsoft.com/en-us/library/bb742535.aspx
>
> I would like to have have a TYPE that's ignore by the provider
> completely and the caller can be sure the provider doesn't mofify
> it. That's why I originally used:
>
> #define GSS_IOV_BUFFER_TYPE_IGNORE 0
>
> I'm fine with keeping GSS_IOV_BUFFER_TYPE_EMPTY but we should defin
> what it means.

Can you think of any reason where we might need something that behaves  
like SECBUFFER_EMPTY?

>> #define GSS_IOV_BUFFER_TYPE_DATA            1   /* Packet data */
>> #define GSS_IOV_BUFFER_TYPE_HEADER          2   /* Mechanism header  
>> */
>> #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS     3   /* Mechanism specific
>> parameters */
>> #define GSS_IOV_BUFFER_TYPE_TRAILER         7   /* Mechanism  
>> trailer */
>> #define GSS_IOV_BUFFER_TYPE_PADDING         9   /* Padding */
>> #define GSS_IOV_BUFFER_TYPE_STREAM          10  /* Complete wrap  
>> token */
>> #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY       11  /* Sign only packet  
>> data */
>
> any reason for not counting from 0-7?

I tried to keep the types aligned with the equivalent SSPI types, to  
make it easier for anyone that might want to build a shim (in either  
direction).

>> #define GSS_IOV_BUFFER_FLAG_MASK            0xFFFF0000
>> #define GSS_IOV_BUFFER_FLAG_ALLOCATE        0x00010000  /*  
>> indicates GSS
>> can allocate */
>
> I think that should be 'indicates GSS should/must allocate'

OK, will fix.

-- Luke



More information about the krbdev mailing list