proposed new Unix QFS Info level

[Conrad Minshall]

For this interface you might want to specify that the number of SIDs
must be either zero or equal to the number of supplementary gids.
Then again, imagine a server for some reason is only able to determine
gid=>SID mappings for some but not all of the gids, in which case we
should define a structure which preserves the gid/SID correspondence.

Conrad

At 2:21 PM -0600 2/6/07, Steve French wrote:
>To address the problem of determining what Unix uid represents this
>authenticated user,
>the following new QFS Info level has been proposed (in the Unix/POSIX QFS
>Info range).   This level
>takes implicit input of the authenticated smb user (what user/password you
>specified on session setup)
>which can be known based on the supplied
>   smb_uid, tid, and tcp socket
>in the smb header of the (empty) QFSInfo level 0x202 request
>
>The proposed response (see below) includes the unix uid, and one or more
>gids which the server
>os associates with this user (and corresponding SIDs if the server supports
>SIDs)
>
>Unix/POSIX "whoami" proposed format:
>
>typedef struct whoami_rsp_data { /* Query FS Info level 0x202 */
>        __u32 flags; /* 0 = Authenticated user 1 = GUEST */
>        __u32 mask /* which flags bits server understands ie 0x0001 */
>        __u64 unix_user_id;
>        __u64 unix_user_gid;
>        __u32 number_of_supplementary_gids; /* may be zero */
>        __u32 number_of_sids; /* may be zero */
>        __u32 length_of_sid_array; /* in bytes - may be zero */
>        __u32 pad; /* reserved - MBZ */
>        /* __u64 gid_array[0];  /* may be empty */
>        /* __u8 * psid_list */  /* may be empty */
>};
>
>Comments?
>
>--
>Thanks,
>
>Steve