Query regards to expose client-pid to fuse process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Query regards to expose client-pid to fuse process

Mohit Agrawal
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 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
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

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

Nithya Balachandran


On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

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

Mohit Agrawal
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 

Regards,
Mohit Agrawal
  

On Fri, Oct 11, 2019 at 4:52 PM Nithya Balachandran <[hidden email]> wrote:


On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

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

Amar Tumballi-2


On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <[hidden email]> 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 <[hidden email]> wrote:


On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

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

Aravinda Vishwanathapura Krishna Murthy
Geo-replication uses this option to identify itself as an internal client

On Sun, Oct 13, 2019 at 11:41 AM Amar Tumballi <[hidden email]> wrote:


On Fri, Oct 11, 2019 at 5:05 PM Mohit Agrawal <[hidden email]> 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 <[hidden email]> wrote:


On Fri, 11 Oct 2019 at 14:56, Mohit Agrawal <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel