<div dir="ltr">On Thu, Sep 26, 2013 at 3:55 AM, Shyamsundar Ranganathan <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
----- Original Message -----<br>
> From: "Shyamsundar Ranganathan" <<a href="mailto:srangana@redhat.com">srangana@redhat.com</a>><br>
> To: <a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a><br>
> Cc: <a href="mailto:anands@redhat.com">anands@redhat.com</a><br>
> Sent: Friday, September 13, 2013 1:48:19 PM<br>
> Subject: RFC/Review: libgfapi object handle based extensions<br>
<br>
><br>
> - We do need the APIs to extend themselves to do any ID based operations, say<br>
> creating with a specific UID/GID rather than the running process UID/GID<br>
> that can prove detrimental in a multi threaded, multi connection handling<br>
> server protocol like the NFS Ganesha implementation<br>
><br>
<br>
</div>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.<br>
<br>
Here is a suggestion for review on achieving the same, (for current code implementation of handle APIs look at, <a href="http://review.gluster.org/#/c/5936/" target="_blank">http://review.gluster.org/#/c/5936/</a> )<br>
<br>
1) Modify the handle based APIs to take in a opctx (operation context, concept borrowed from Ganesha)<br>
<br>
So, instead of,<br>
glfs_h_creat (struct glfs *fs, struct glfs_object *parent, const char *path, int flags, mode_t mode, struct stat *stat)<br>
it would be,<br>
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)<br>
<br>
Where,<br>
struct glfs_optctx {<br>
uid_t caller_uid;<br>
gid_t caller_gid;<br>
}<br>
<br>
Later as needed this operation context can be extended for other needs like, client connection address or ID, supplementary groups, etc.<br>
<br>
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)<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Avati</div></div></div></div>