If the number of users who accesses files is small, why not have a thread per user, which handles all the requests of that particular user? You can maintain a map from uid to thread, and have the thread be notified when gRPC gets a request.
Another alternative is check the file permissions in your application, and grant the server access to all the files. On Wednesday, August 8, 2018 at 1:19:12 PM UTC-7, [email protected] wrote: > > Hi, I started using gRPC about one year ago. I mainly use gRPC in C++ and > Python on Linux and Windows to improve parts of the software system used in > my company. > > In most of our use cases, we need to transfer large volume of binary data > between machines. So streaming feature of gRPC is really helpful. But > recently, we got some difficulties related to user permission. The server > runs on a Linux machine and provides services for file access. To fit the > existing software system, we want to provide the normal unix file access > based on the client's actual user and group id. But the trouble is that the > threads created by the server are owned by the user who starts the server. > We have tried to start the server with root permission and set the > effective uid of the thread for every request, then there is higher > overhead. I am wondering if there are better ways to solve this problem > using gRPC. Any help will be appreciated. > > Weiguo > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0288225a-5d39-46c9-acce-8a5ad2ae0b1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
