Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions

[Shyamsundar Ranganathan]

----- Original Message -----
> From: "Shyamsundar Ranganathan" <address@hidden>
> To: address@hidden
> Cc: address@hidden
> Sent: Friday, September 13, 2013 1:48:19 PM
> Subject: RFC/Review: libgfapi object handle based extensions

> 
> - We do need the APIs to extend themselves to do any ID based operations, say
> creating with a specific UID/GID rather than the running process UID/GID
> that can prove detrimental in a multi threaded, multi connection handling
> server protocol like the NFS Ganesha implementation
> 

In continuation of the original mail, we need to handle the one item above. 
Where we need to pass in the UID/GID to be used when performing the operations.

Here is a suggestion for review on achieving the same, (for current code 
implementation of handle APIs look at, http://review.gluster.org/#/c/5936/ )

1) Modify the handle based APIs to take in a opctx (operation context, concept 
borrowed from Ganesha)

So, instead of,
glfs_h_creat (struct glfs *fs, struct glfs_object *parent, const char *path, 
int flags, mode_t mode, struct stat *stat)
it would be,
glfs_h_creat (struct glfs *fs, <struct glfs_optctx *opctx>, struct glfs_object 
*parent, const char *path, int flags, mode_t mode, struct stat *stat)

Where, 
struct glfs_optctx {
    uid_t caller_uid;
    gid_t caller_gid;
}

Later as needed this operation context can be extended for other needs like, 
client connection address or ID, supplementary groups, etc.

2) Internal to the glfs APIs (esp. handle based APIs), use this to set thread 
local variables (UID/GID) that the syncop frame creation can pick up in 
addition to the current probe of geteuid/egid. (as suggested by Avati)

If the basic construct looks fine I will amend my current review with this 
change in the create API and syncop.h (etc.), and once reviewed extend it to 
other handle based APIs as appropriate.

Shyam