Fix: on some systems UIDs are > 16 bits

[joshStillerman]

On systems using active directory uids can be constructed from
AD SIDs and may have bits in their high word set. This PR
addresses #2375

If their are bits set in the high word of the UID then do not or in
the group.

When displaying in TCL, if the the low 16 bits of the owner do not
translate to a user, then try to translate all 32 bits to an owner

[joshStillerman]

Address sanitizer failing in tditest/mdsip0

DoMessage calls GetMdsMsgTOC which allocates the returned message. The macro FREE_IF calls pthread_cleanup_pop which only executes the cleanup if there is a message.

It is not clear the malloc of the message in GetMdsMsgTOC would be cleaned up if the thread cleanup was executed, and it seems that FREE_IF does not do anything with its 1st argument, so does not care if the message was allocated.

This ASAN error should be unrelated to the PR in question.

[zack-vii]

yes it should be unrelated. i dont now how thois cpuld bbe fixed,. the cleanup should be executed if the execution doed not pass by FREE_IF in the regular way, purpose of the pthread cleanup (?) i am on vacation atm.. when i aam back i can dig a bit deeper into this.

[zack-vii]

test this please

[zack-vii]

How about we set a free bit in flags2 of the nci e.g. NciM_32BIT_UID_NCI 0x80

#define NciM_DATA_IN_ATT_BLOCK 0x01
#define NciV_DATA_IN_ATT_BLOCK 0
#define NciM_ERROR_ON_PUT 0x02
#define NciV_ERROR_ON_PUT 1
#define NciM_DATA_CONTIGUOUS 0x04
#define NciV_DATA_CONTIGUOUS 2
#define NciM_NON_VMS 0x08
#define NciV_NON_VMS 3
#define NciM_EXTENDED_NCI 0x10
#define NciV_EXTENDED_NCI 4
#define NciM_32BIT_UID_NCI 0x20
#define NciV_32BIT_UID_NCI 5

if the uid has high bits the flag will be set nad gid will be dropped. otherwise the bit is cleared and gid is attached. reading the uid is according to the flag. if user or group is not found it must have been deleted.

[joshStillerman]

Actually I ran into this because someone was wondering who wrote to some nodes on a tree, and I could not tell because the high bits of the UID. we ORed with the GID.

I think this 'quick fix'. That treats the 32 bits as a UID if the low 16 bits are not valid (in tcl dir /full) and fills it in with either UID and GID if there are no high bits in the UID is not bad.

I would like to go ahead with this, so I can tell who is writing data on my system.

[joshStillerman]

replaced by #2379