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

Aravinda Vishwanathapura Krishna Murthy avishwan at redhat.com
Mon Oct 14 05:17:18 UTC 2019


Geo-replication uses this option to identify itself as an internal client

On Sun, Oct 13, 2019 at 11:41 AM Amar Tumballi <amarts at gmail.com> wrote:

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

-- 
regards
Aravinda VK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20191014/7fc5b16d/attachment.html>


More information about the Gluster-devel mailing list