gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anand Avati
Subject: Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions
Date: Sun, 29 Sep 2013 21:57:56 -0700

On Thu, Sep 26, 2013 at 3:55 AM, Shyamsundar Ranganathan <address@hidden> wrote:

----- 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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]