On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <moagr...@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 <nbala...@redhat.com> > wrote: > >> >> >> On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <moagr...@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@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@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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
