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

[Amar Tumballi]

On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <moagrawa at redhat.com> wrote:

> Hi,
>
> Yes, you are right it is not a default value.
>
> We can assign the client_pid only while volume has mounted after through a
> glusterfs binary directly like
> /usr/local/sbin/glusterfs --process-name fuse --volfile-server=192.168.1.3
> --client-pid=-3 --volfile-id=/test /mnt1
>
>
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.

-Amar



> Regards,
> Mohit Agrawal
>
>
> On Fri, Oct 11, 2019 at 4:52 PM Nithya Balachandran <nbalacha at redhat.com>
> wrote:
>
>>
>>
>> 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
>>>
>>> _______________________________________________
>
> 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/20191013/87924e8f/attachment.html>