On Thu, Sep 26, 2013 at 3:55 AM, Shyamsundar Ranganathan < srang...@redhat.com> wrote:
> > ----- Original Message ----- > > From: "Shyamsundar Ranganathan" <srang...@redhat.com> > > To: gluster-devel@nongnu.org > > Cc: ana...@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. > > I am somewhat hesitant to expose a structure to be filled by the user, where the structure can "grow" over time. Providing APIs like glfs_setfsuid()/glfs_setfsgid()/glfs_setgroups(), which internally uses thread local variables to communicate the values to syncop_create_frame() is probably a cleaner approach. Avati
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel