Message ID | 1568196917-25674-1-git-send-email-chakragithub@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | fuse:send filep uid as part of fuse write req | expand |
On Wed, Sep 11, 2019 at 12:15 PM Chakra Divi <chakragithub@gmail.com> wrote: > > In current code in fuse write request current_fsuid is sent, > however this creates an issue in sudo execution context. > Changes to consider uid and gid from file struture pointer > that is created as part of open file instead of current_fsuid,gid > > Steps to reproduce the issue: > 1) create user1 and user2 > 2) create a file1 with user1 on fusemount > 3) change the file1 permissions to 600 > 4) execute the following command > user1@linux# sudo -u user2 whoami >> /fusemnt/file1 > Here write fails with permission denied error Not sure what's the issue here. If filesystem wants to check open creds, it should do so with the creds sent at open. Does that solve your problem? Thanks, Miklos
On Thu, Sep 12, 2019 at 6:59 AM Chakra Divi <chakragithub@gmail.com> wrote: > > Hi Miklos, > > On Wed, Sep 11, 2019 at 5:05 PM Miklos Szeredi <miklos@szeredi.hu> wrote: >> >> On Wed, Sep 11, 2019 at 12:15 PM Chakra Divi <chakragithub@gmail.com> wrote: >> > >> > In current code in fuse write request current_fsuid is sent, >> > however this creates an issue in sudo execution context. >> > Changes to consider uid and gid from file struture pointer >> > that is created as part of open file instead of current_fsuid,gid >> > >> > Steps to reproduce the issue: >> > 1) create user1 and user2 >> > 2) create a file1 with user1 on fusemount >> > 3) change the file1 permissions to 600 >> > 4) execute the following command >> > user1@linux# sudo -u user2 whoami >> /fusemnt/file1 >> > Here write fails with permission denied error >> >> Not sure what's the issue here. If filesystem wants to check open >> creds, it should do so with the creds sent at open. >> >> Does that solve your problem? >> > > Are you saying that our filesystem should store the credentials in open call, ignore the credentials in write request and use open credentials instead Yes. And even that would be dubious in case of mmap-ed writes or with FUSE_WRITEBACK_CACHE because the information about which open file instance received the modification is lost. So generally credential checking on writeback is useless. Not sure what NFS does, because there's no way to get around those rules. Thanks, Miklos
diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 5ae2828..e1d223c 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -1134,6 +1134,7 @@ static ssize_t fuse_perform_write(struct kiocb *iocb, struct inode *inode = mapping->host; struct fuse_conn *fc = get_fuse_conn(inode); struct fuse_inode *fi = get_fuse_inode(inode); + struct file *file = iocb->ki_filp; int err = 0; ssize_t res = 0; @@ -1150,6 +1151,9 @@ static ssize_t fuse_perform_write(struct kiocb *iocb, if (IS_ERR(req)) { err = PTR_ERR(req); break; + } else { + req->in.h.uid = file->f_cred->uid.val; + req->in.h.gid = file->f_cred->gid.val; } count = fuse_fill_write_pages(req, mapping, ii, pos);
In current code in fuse write request current_fsuid is sent, however this creates an issue in sudo execution context. Changes to consider uid and gid from file struture pointer that is created as part of open file instead of current_fsuid,gid Steps to reproduce the issue: 1) create user1 and user2 2) create a file1 with user1 on fusemount 3) change the file1 permissions to 600 4) execute the following command user1@linux# sudo -u user2 whoami >> /fusemnt/file1 Here write fails with permission denied error on nfs and ext4 - above use case is working, but on fuse its failing Signed-off-by: Chakra Divi <chakragithub@gmail.com> --- fs/fuse/file.c | 4 ++++ 1 file changed, 4 insertions(+)