Geo-replication uses this option to identify itself as an internal client
On Sun, Oct 13, 2019 at 11:41 AM Amar Tumballi <amarts@xxxxxxxxx> wrote:
_______________________________________________On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <moagrawa@xxxxxxxxxx> 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 /mnt1I 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.-AmarRegards,Mohit Agrawal_______________________________________________On Fri, Oct 11, 2019 at 4:52 PM Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <moagrawa@xxxxxxxxxx> 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 thesource of fop request based on PID.If PID value is -ve xlator considers the request has come from an internalclient 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 PIDin 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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
--
regards
Aravinda VK_______________________________________________ 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@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
