/*-1* SPDX-License-Identifier: BSD-3-Clause2*3* Copyright (c) 2007-2009 Google Inc. and Amit Singh4* All rights reserved.5*6* Redistribution and use in source and binary forms, with or without7* modification, are permitted provided that the following conditions are8* met:9*10* * Redistributions of source code must retain the above copyright11* notice, this list of conditions and the following disclaimer.12* * Redistributions in binary form must reproduce the above13* copyright notice, this list of conditions and the following disclaimer14* in the documentation and/or other materials provided with the15* distribution.16* * Neither the name of Google Inc. nor the names of its17* contributors may be used to endorse or promote products derived from18* this software without specific prior written permission.19*20* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS21* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT22* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR23* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT24* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,25* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT26* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,27* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY28* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT29* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE30* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.31*32* Copyright (C) 2005 Csaba Henk.33* All rights reserved.34*35* Copyright (c) 2019 The FreeBSD Foundation36*37* Portions of this software were developed by BFF Storage Systems, LLC under38* sponsorship from the FreeBSD Foundation.39*40* Redistribution and use in source and binary forms, with or without41* modification, are permitted provided that the following conditions42* are met:43* 1. Redistributions of source code must retain the above copyright44* notice, this list of conditions and the following disclaimer.45* 2. Redistributions in binary form must reproduce the above copyright46* notice, this list of conditions and the following disclaimer in the47* documentation and/or other materials provided with the distribution.48*49* THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND50* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE51* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE52* ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE53* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL54* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS55* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)56* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT57* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY58* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF59* SUCH DAMAGE.60*/6162#ifndef _FUSE_FILE_H_63#define _FUSE_FILE_H_6465#include <sys/types.h>66#include <sys/fcntl.h>67#include <sys/stat.h>68#include <sys/mman.h>69#include <sys/vnode.h>7071/*72* The fufh type is the access mode of the fuse file handle. It's the portion73* of the open(2) flags related to permission.74*/75typedef enum fufh_type {76FUFH_INVALID = -1,77FUFH_RDONLY = O_RDONLY,78FUFH_WRONLY = O_WRONLY,79FUFH_RDWR = O_RDWR,80FUFH_EXEC = O_EXEC,81} fufh_type_t;8283/*84* FUSE File Handles85*86* The FUSE protocol says that a server may assign a unique 64-bit file handle87* every time that a file is opened. Effectively, that's once for each file88* descriptor.89*90* Unfortunately, the VFS doesn't help us here. VOPs don't have a91* struct file* argument. fileops do, but many syscalls bypass the fileops92* layer and go straight to a vnode. Some, like writing from cache, can't93* track a file handle even in theory. The entire concept of the file handle94* is a product of FUSE's Linux origins; Linux lacks vnodes and almost every95* file system operation takes a struct file* argument.96*97* Since FreeBSD's VFS is more file descriptor-agnostic, we must store FUSE98* filehandles in the vnode. One option would be to only store a single file99* handle and never open FUSE files concurrently. That's what NetBSD does.100* But that violates FUSE's security model. FUSE expects the server to do all101* authorization (except when mounted with -o default_permissions). In order102* to do that, the server needs us to send FUSE_OPEN every time somebody opens103* a new file descriptor.104*105* Another option would be to never open FUSE files concurrently, but send a106* FUSE_ACCESS prior to every open after the first. That would give the server107* the opportunity to authorize the access. Unfortunately, the FUSE protocol108* makes ACCESS optional. File systems that don't implement it are assumed to109* authorize everything. A survey of 32 fuse file systems showed that only 14110* implemented access. Among the laggards were a few that really ought to be111* doing server-side authorization.112*113* So we do something hacky, similar to what OpenBSD, Illumos, and OSXFuse do.114* we store a list of file handles, one for each combination of vnode, uid,115* gid, pid, and access mode. When opening a file, we first check whether116* there's already a matching file handle. If so, we reuse it. If not, we117* send FUSE_OPEN and create a new file handle. That minimizes the number of118* open file handles while still allowing the server to authorize stuff.119*120* VOPs that need a file handle search through the list for a close match.121* They can't be guaranteed of finding an exact match because, for example, a122* process may have changed its UID since opening the file. Also, most VOPs123* don't know exactly what permission they need. Is O_RDWR required or is124* O_RDONLY good enough? So the file handle we end up using may not be exactly125* the one we're supposed to use with that file descriptor. But if the FUSE126* file system isn't too picky, it will work. (FWIW even Linux sometimes127* guesses the file handle, during writes from cache or most SETATTR128* operations).129*130* I suspect this mess is part of the reason why neither NFS nor 9P have an131* equivalent of FUSE file handles.132*/133struct fuse_filehandle {134LIST_ENTRY(fuse_filehandle) next;135136/* The filehandle returned by FUSE_OPEN */137uint64_t fh_id;138139/*140* flags returned by FUSE_OPEN141* Supported flags: FOPEN_DIRECT_IO, FOPEN_KEEP_CACHE, FOPEN_NOFLUSH142* Unsupported:143* FOPEN_NONSEEKABLE: Adding support would require a new per-file144* or per-vnode attribute, which would have to be checked by145* kern_lseek (and others) for every file system. The benefit is146* dubious, since I'm unaware of any file systems in ports that use147* this flag.148*/149uint32_t fuse_open_flags;150151/* The access mode of the file handle */152fufh_type_t fufh_type;153154/* Credentials used to open the file */155gid_t gid;156pid_t pid;157uid_t uid;158};159160#define FUFH_IS_VALID(f) ((f)->fufh_type != FUFH_INVALID)161162/*163* Get the flags to use for FUSE_CREATE, FUSE_OPEN and FUSE_RELEASE164*165* These are supposed to be the same as the flags argument to open(2).166* However, since we can't reliably associate a fuse_filehandle with a specific167* file descriptor it would would be dangerous to include anything more than168* the access mode flags. For example, suppose we open a file twice, once with169* O_APPEND and once without. Then the user pwrite(2)s to offset using the170* second file descriptor. If fusefs uses the first file handle, then the171* server may append the write to the end of the file rather than at offset 0.172* To prevent problems like this, we only ever send the portion of flags173* related to access mode.174*175* It's essential to send that portion, because FUSE uses it for server-side176* authorization.177*/178static inline int179fufh_type_2_fflags(fufh_type_t type)180{181int oflags = -1;182183switch (type) {184case FUFH_RDONLY:185case FUFH_WRONLY:186case FUFH_RDWR:187case FUFH_EXEC:188oflags = type;189break;190default:191break;192}193194return oflags;195}196197bool fuse_filehandle_validrw(struct vnode *vp, int mode,198struct ucred *cred, pid_t pid);199int fuse_filehandle_get(struct vnode *vp, int fflag,200struct fuse_filehandle **fufhp, struct ucred *cred,201pid_t pid);202int fuse_filehandle_get_anyflags(struct vnode *vp,203struct fuse_filehandle **fufhp, struct ucred *cred,204pid_t pid);205int fuse_filehandle_getrw(struct vnode *vp, int fflag,206struct fuse_filehandle **fufhp, struct ucred *cred,207pid_t pid);208209void fuse_filehandle_init(struct vnode *vp, fufh_type_t fufh_type,210struct fuse_filehandle **fufhp, struct thread *td,211const struct ucred *cred,212const struct fuse_open_out *foo);213int fuse_filehandle_open(struct vnode *vp, int mode,214struct fuse_filehandle **fufhp, struct thread *td,215struct ucred *cred);216int fuse_filehandle_close(struct vnode *vp, struct fuse_filehandle *fufh,217struct thread *td, struct ucred *cred);218219void fuse_file_init(void);220void fuse_file_destroy(void);221222#endif /* _FUSE_FILE_H_ */223224225