Re: Query regards to expose client-pid to fuse process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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 /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@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 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@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


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux