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

[Shyamsundar Ranganathan]

----- Original Message -----
> From: "Shyamsundar Ranganathan" <srangana at redhat.com>
> To: gluster-devel at nongnu.org
> Cc: anands at redhat.com
> 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