<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div> </div><div>Yes, you are right it is not a default value.</div><div><br></div><div>We can assign the client_pid only while volume has mounted after through a glusterfs binary directly like </div><div><span style="background-color:rgb(248,249,250);color:rgb(32,33,36);font-family:Roboto,sans-serif;font-size:14px;white-space:pre-wrap">/usr/local/sbin/glusterfs --process-name fuse --volfile-server=192.168.1.3 --client-pid=-3 --volfile-id=/test /mnt1</span> </div><div><br></div></div></blockquote><div><br></div><div>I agree that this is in general risky, and good to fix. But as the check for this happens after basic auth check in RPC (ip/user based), it should be OK. Good to open a github issue and have some possible design options so we can have more discussions on this.</div><div><br></div><div>-Amar</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Regards,</div><div>Mohit Agrawal</div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 4:52 PM Nithya Balachandran <<a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <<a href="mailto:moagrawa@redhat.com" target="_blank">moagrawa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br> I have a query specific to authenticate a client based on the PID (client-pid).<br> It can break the bricks xlator functionality, Usually, on the brick side we take a decision about the <div> source of fop request based on PID.If PID value is -ve xlator considers the request has come from an internal </div><div> client otherwise it has come from an external client.</div><div><div><br> If a user has mounted the volume through fuse after provide --client-pid to command line argument similar to internal client PID </div><div> in that case brick_xlator consider external fop request also as an internal and it will break functionality.</div><div><br> We are checking pid in (lease, posix-lock, worm, trash) xlator to know about the source of the fops.<br> Even there are other brick xlators also we are checking specific PID value for all internal<br> clients that can be break if the external client has the same pid.<br> </div><div> My query is why we need to expose client-pid as an argument to the fuse process?<br></div></div></div></blockquote><div><br></div><div><br></div><div>I don't think this is a default value to the fuse mount. One place where this helps us is with the script based file migration and rebalance - we can provide a negative pid to the special client mount to ensure these fops are also treated as internal fops.</div><div><br></div><div>In the meantime I do not see the harm in having this option available as it allows a specific purpose. Are there any other client processes that use this?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> I think we need to resolve it. Please share your view on the same.</div><div> </div><div>Thanks,<br>Mohit Agrawal<br></div></div></div>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>