08 Oct, 2016
1 commit
-
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.Signed-off-by: Andreas Gruenbacher
Signed-off-by: Al Viro
06 Jul, 2016
4 commits
-
In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
since dmesg is global, init_user_ns should be used here instead.In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
upcall structures are populated with uids/gids that have been mapped into
the caller's namespace. However, those upcall structures are read by
another process (the userspace filesystem driver), and that process might
be running in another namespace. This effectively lets any user spoof its
uid and gid as seen by the userspace filesystem driver.To fix the second issue, I just construct the opcall structures with
init_user_ns uids/gids and require the filesystem server to run in the
init namespace. Since orangefs is full of global state anyway (as the error
message in DUMP_DEVICE_ERROR explains, there can only be one userspace
orangefs filesystem driver at once), that shouldn't be a problem.[
Why does orangefs even exist in the kernel if everything does upcalls into
userspace? What does orangefs do that couldn't be done with the FUSE
interface? If there is no good answer to those questions, I'd prefer to see
orangefs kicked out of the kernel. Can that be done for something that
shipped in a release?According to commit f7ab093f74bf ("Orangefs: kernel client part 1"), they
even already have a FUSE daemon, and the only rational reason (apart from
"but most of our users report preferring to use our kernel module instead")
given for not wanting to use FUSE is one "in-the-works" feature that could
probably be integated into FUSE instead.
]This patch has been compile-tested.
Signed-off-by: Jann Horn
Signed-off-by: Mike Marshall -
Mike,
On Fri, Jun 3, 2016 at 9:44 PM, Mike Marshall wrote:
> We use the return value in this one line you changed, our userspace code gets
> ill when we send it (-ENOMEM +1) as a key length...ah, my mistake. Here's a fixed version.
Thanks,
AndreasSigned-off-by: Andreas Gruenbacher
Signed-off-by: Mike Marshall -
Orangefs has a catch-all xattr handler that effectively does what the
trusted handler does already.Signed-off-by: Andreas Gruenbacher
Signed-off-by: Mike Marshall -
The ORANGEFS_XATTR_INDEX_ defines are unused; the ORANGEFS_XATTR_NAME_
defines only obfuscate the code.Signed-off-by: Andreas Gruenbacher
Signed-off-by: Mike Marshall
28 May, 2016
1 commit
-
preparation for similar switch in ->setxattr() (see the next commit for
rationale).Signed-off-by: Al Viro
03 May, 2016
1 commit
-
The rest of work.xattr stuff isn't needed for this branch
11 Apr, 2016
1 commit
-
... and do not assume they are already attached to each other
Signed-off-by: Al Viro
09 Apr, 2016
2 commits
-
Suggested by David Binderman
The former can potentially be a performance win over the latter.memcpy(d, s, len);
memset(d+len, c, size-len);memset(d, c, size);
memcpy(d, s, len);Signed-off-by: Mike Marshall
-
1. It is nonsense to test for negative size_t, suggested by
David Binderman2. By the time Orangefs gets called, the vfs has ensured that
name != NULL, and that buffer and size are sane.Signed-off-by: Mike Marshall
18 Mar, 2016
2 commits
-
Signed-off-by: Martin Brandenburg
Signed-off-by: Mike Marshall -
Signed-off-by: Martin Brandenburg
Signed-off-by: Mike Marshall
18 Dec, 2015
1 commit
-
Signed-off-by: Mike Marshall
05 Dec, 2015
1 commit
-
Also changed references within source files that referred to
header files whose names had changed.Signed-off-by: Mike Marshall
04 Dec, 2015
1 commit
-
OrangeFS was formerly known as PVFS2 and retains the name in many places.
I leave the device /dev/pvfs2-req since this affects userspace.
I leave the filesystem type pvfs2 since this affects userspace. Further
the OrangeFS sysint library reads fstab for an entry of type pvfs2
independently of kernel mounts.I leave extended attribute keys user.pvfs2 and system.pvfs2 as the
sysint library understands these.I leave references to userspace binaries still named pvfs2.
I leave the filenames.
Signed-off-by: Yi Liu
[martin@omnibond.com: clairify above constraints and merge]
Signed-off-by: Martin Brandenburg
Signed-off-by: Mike Marshall
17 Nov, 2015
1 commit
-
On Wed, Nov 11, 2015 at 10:19:48AM +0000, Al Viro wrote:
> I'll cook the minimal fixup for API change after I get some sleep and
> send it your way, unless somebody gets there first...This should do it - switches ->ioctl() to pvfs2_inode_[gs]etxattr() and
converts xattr_handler ->[gs]et() to new API.Signed-off-by: Al Viro
Signed-off-by: Mike Marshall
03 Oct, 2015
2 commits
-
Don't check for negative rc from boolean.
Don't pointlessly initialize variables, it short-circuits
gcc's uninitialized variable warnings. And max_new_nr_segs
can never be zero, so don't check for it.Preserve original kstrdup pointer for freeing later.
Don't check for negative value in unsigned variable.
Signed-off-by: Mike Marshall
-
Signed-off-by: Mike Marshall