[Gluster-devel] Query regards to expose client-pid to fuse process

[Nithya Balachandran]

On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <moagrawa at redhat.com> wrote:

> Hi,
>
>   I have a query specific to authenticate a client based on the PID
> (client-pid).
>   It can break the bricks xlator functionality, Usually, on the brick side
> we take a decision about the
>    source of fop request based on PID.If PID value is -ve xlator considers
> the request has come from an internal
>   client otherwise it has come from an external client.
>
>   If a user has mounted the volume through fuse after provide --client-pid
> to command line argument similar to internal client PID
>   in that case brick_xlator consider external fop request also as an
> internal and it will break functionality.
>
>   We are checking pid in (lease, posix-lock, worm, trash) xlator to know
> about the source of the fops.
>   Even there are other brick xlators also we are checking specific PID
> value for all internal
>   clients that can be break if the external client has the same pid.
>
>   My query is why we need to expose client-pid as an argument to the fuse
> process?
>


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.

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?

   I think we need to resolve it. Please share your view on the same.
>
> Thanks,
> Mohit Agrawal
> _______________________________________________
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/118564314
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/118564314
>
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20191011/de904532/attachment.html>