From: Jean-Pierre A. <jea...@wa...> - 2014-01-21 07:27:35
|
Hi, Teijo Holzer wrote: > Hi, > > maybe there is an issue with this particular approach of accessing a file > struct from a foreign process, which I would agree is probably not the cleanest > solution (security, stability). > > Maybe we can try a different approach. There is already a standard mechanism > for passing open file descriptors between different unrelated processes via > sendmsg/recvmsg: > > SCM_RIGHTS (see man 7 unix and scm_fp_copy in net/core/scm.c) > > This essentially allows the dup'ing of open file descriptors across unrelated > process boundaries via a socket. > > So another suggested approach for this patch would be: > > - add a FOPEN_SCM_RIGHTS open_flag > - the FUSE daemon opens the file, sets FOPEN_SCM_RIGHTS and returns the fd > - the kernel uses a variation of scm_fp_copy to dup this fd into the client > process and returns that fd > - read/write can now operate directly on this fd (no need to access any parts > of the the FUSE daemon process) How does the user-space file system gets called when the client issues a read or write ? Jean-Pierre > - the FUSE daemon can even close its own fd now (as the client process has a dup) > > This seems to be a cleaner solution using existing approved mechanisms for fd > exchanging between processes. > > Miklos, is it worth implementing this approach to be considered for a patch or > is it likely to be rejected ? > > Cheers, > > T. > > On 18/01/14 02:38, Sven Utcke wrote: >> Hi, >> >>> Therefore, we have made some changes to the kernel FUSE driver to >>> short-circuit the read/write paths against the file descriptor >>> returned by open, so they never hit the FUSE daemon. >> I wish you all the best of luck with your patch - alas, past >> experience shows that patches of that sort are not exactly welcome, >> even though many of us would wish they were... >> >> Sven >> > |