aboutsummaryrefslogtreecommitdiffstats
path: root/security/smack (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2015-04-11export __vfs_read()Al Viro1-8/+5
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11autofs: switch to __vfs_write()Al Viro2-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11new helper: __vfs_write()Al Viro2-12/+17
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11switch hugetlbfs to ->read_iter()Al Viro1-58/+34
... and fix the case when the area we are asked to read crosses a hugepage boundary Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11coda: switch to ->read_iter/->write_iterAl Viro1-25/+15
... and request the same from the local cache - all filesystems with anything usable for that support those already. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11ncpfs: switch to ->read_iter/->write_iterAl Viro3-63/+37
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11net/9p: remove (now-)unused helpersAl Viro2-43/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11p9_client_attach(): set fid->uid correctlyAl Viro1-0/+1
it's almost always equal to current_fsuid(), but there's an exception - if the first writeback fid is opened by non-root *and* that happens before root has done any lookups in /, we end up doing attach for root. The current code leaves the resulting FID owned by root from the server POV and by non-root from the client one. Unfortunately, it means that e.g. massive dcache eviction will leave that user buggered - they'll end up redoing walks from / *and* picking that FID every time. As soon as they try to create something, the things will get nasty. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: we are leaking glock.client_id in v9fs_file_getlock()Al Viro1-0/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: switch to ->read_iter/->write_iterAl Viro1-44/+39
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: get rid of v9fs_direct_file_read()Al Viro2-51/+12
do it in ->direct_IO()... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: switch p9_client_read() to passing struct iov_iter *Al Viro7-183/+108
... and make it loop Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: get rid of v9fs_direct_file_write()Al Viro2-82/+17
just handle it in ->direct_IO() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: fold v9fs_file_write_internal() into the callerAl Viro2-49/+30
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: switch ->writepage() to direct use of p9_client_write()Al Viro1-22/+13
Don't mess with kmap() - just use ITER_BVEC. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-119p: switch p9_client_write() to passing it struct iov_iter *Al Viro4-97/+62
... and make it loop until it's done Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11net/9p: switch the guts of p9_client_{read,write}() to iov_iterAl Viro4-133/+147
... and have get_user_pages_fast() mapping fewer pages than requested to generate a short read/write. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11nommu: use __vfs_read()Al Viro1-2/+2
... instead of open-coding the call of ->read() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11acct: check FMODE_CAN_WRITEAl Viro1-1/+1
it's not calling ->write() directly anymore. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11aio_run_iocb(): kill dead checkAl Viro1-7/+0
We check if ->ki_pos is positive. However, by that point we have already done rw_verify_area(), which would have rejected such unless the file had been one of /dev/mem, /dev/kmem and /proc/kcore. All of which do not have vectored rw methods, so we would've bailed out even earlier. This check had been introduced before rw_verify_area() had been added there - in fact, it was a subset of checks done on sync paths by rw_verify_area() (back then the /dev/mem exception didn't exist at all). The rest of checks (mandatory locking, etc.) hadn't been added until later. Unfortunately, by the time the call of rw_verify_area() got added, the /dev/mem exception had already appeared, so it wasn't obvious that the older explicit check downstream had become dead code. It *is* a dead code, though, since the few files for which the exception applies do not have ->aio_{read,write}() or ->{read,write}_iter() and for them we won't reach that check anyway. What's more, even if we ever introduce vectored methods for /dev/mem and friends, they'll have to cope with negative positions anyway, since readv(2) and writev(2) are using the same checks as read(2) and write(2) - i.e. rw_verify_area(). Let's bury it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11ioctx_alloc(): remove pointless checkAl Viro1-2/+1
Way, way back kiocb used to be picked from arrays, so ioctx_alloc() checked for multiplication overflow when calculating the size of such array. By the time fs/aio.c went into the tree (in 2002) they were already allocated one-by-one by kmem_cache_alloc(), so that check had already become pointless. Let's bury it... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11lustre: kill unused members of struct vvp_thread_infoAl Viro1-2/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11expand __fuse_direct_write() in both callersAl Viro1-25/+17
it's actually shorter that way *and* later we'll want iocb in scope of generic_write_check() caller. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11fuse: switch fuse_direct_io_file_operations to ->{read,write}_iter()Al Viro1-17/+12
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11cuse: switch to iov_iterAl Viro1-17/+10
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11sg_start_req(): use import_iovec()Al Viro1-11/+5
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11sg_start_req(): make sure that there's not too many elements in iovecAl Viro1-0/+3
unfortunately, allowing an arbitrary 16bit value means a possibility of overflow in the calculation of total number of pages in bio_map_user_iov() - we rely on there being no more than PAGE_SIZE members of sum in the first loop there. If that sum wraps around, we end up allocating too small array of pointers to pages and it's easy to overflow it in the second loop. X-Coverup: TINC (and there's no lumber cartel either) Cc: stable@vger.kernel.org # way, way back Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11blk_rq_map_user(): use import_single_range()Al Viro1-3/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11sg_io(): use import_iovec()Al Viro1-7/+5
... and don't skip access_ok() validation. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11process_vm_access: switch to {compat_,}import_iovec()Al Viro1-23/+12
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11switch keyctl_instantiate_key_common() to iov_iterAl Viro3-72/+40
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11switch {compat_,}do_readv_writev() to {compat_,}import_iovec()Al Viro1-16/+16
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11aio_setup_vectored_rw(): switch to {compat_,}import_iovec()Al Viro1-19/+9
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11vmsplice_to_user(): switch to import_iovec()Al Viro1-16/+11
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11kill aio_setup_single_vector()Al Viro1-17/+1
identical to import_single_range() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11aio: simplify arguments of aio_setup_..._rw()Al Viro1-28/+17
We don't need req in either of those. We don't need nr_segs in caller. We don't really need len in caller either - iov_iter_count(&iter) will do. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11aio: lift iov_iter_init() into aio_setup_..._rw()Al Viro1-6/+11
the only non-trivial detail is that we do it before rw_verify_area(), so we'd better cap the length ourselves in aio_setup_single_rw() case (for vectored case rw_copy_check_uvector() will do that for us). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11lift iov_iter into {compat_,}do_readv_writev()Al Viro1-31/+23
get it closer to matching {compat_,}rw_copy_check_uvector(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11NFS: fix BUG() crash in notify_change() with patch to chown_common()Andrew Elble1-1/+1
We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS. 1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) 6de0ec00ba8d ("VFS: make notify_change pass ATTR_KILL_S*ID to setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_S*ID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination. 3.) 27ac0ffeac80 ("locks: break delegations on any attribute modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2. 4.) The path that that triggers this is via fs/open.c:chmod_common(). The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr. Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset. There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this. Fixes: 27ac0ffeac80 ("locks: break delegations on any attribute modification") Reported-by: Eric Meddaugh <etmsys@rit.edu> Tested-by: Eric Meddaugh <etmsys@rit.edu> Signed-off-by: Andrew Elble <aweits@rit.edu> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11dcache: return -ESTALE not -EBUSY on distributed fs raceJ. Bruce Fields1-1/+1
On a distributed filesystem it's possible for lookup to discover that a directory it just found is already cached elsewhere in the directory heirarchy. The dcache won't let us keep the directory in both places, so we have to move the dentry to the new location from the place we previously had it cached. If the parent has changed, then this requires all the same locks as we'd need to do a cross-directory rename. But we're already in lookup holding one parent's i_mutex, so it's too late to acquire those locks in the right order. The (unreliable) solution in __d_unalias is to trylock() the required locks and return -EBUSY if it fails. I see no particular reason for returning -EBUSY, and -ESTALE is already the result of some other lookup races on NFS. I think -ESTALE is the more helpful error return. It also allows us to take advantage of the logic Jeff Layton added in c6a9428401c0 "vfs: fix renameat to retry on ESTALE errors" and ancestors, which hopefully resolves some of these errors before they're returned to userspace. I can reproduce these cases using NFS with: ssh root@$client ' mount -olookupcache=pos '$server':'$export' /mnt/ mkdir /mnt/TO mkdir /mnt/DIR touch /mnt/DIR/test.txt while true; do strace -e open cat /mnt/DIR/test.txt 2>&1 | grep EBUSY done ' ssh root@$server ' while true; do mv $export/DIR $export/TO/DIR mv $export/TO/DIR $export/DIR done ' It also helps to add some other concurrent use of the directory on the client (e.g., "ls /mnt/TO"). And you can replace the server-side mv's by client-side mv's that are repeatedly killed. (If the client is interrupted while waiting for the RENAME response then it's left with a dentry that has to go under one parent or the other, but it doesn't yet know which.) Acked-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11NTFS: Version 2.1.32 - Update file write from aio_write to write_iter.Anton Altaparmakov2-477/+308
Signed-off-by: Anton Altaparmakov <anton@tuxera.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11VFS: Add iov_iter_fault_in_multipages_readable()Anton Altaparmakov2-0/+27
simillar to iov_iter_fault_in_readable() but differs in that it is not limited to faulting in the first iovec and instead faults in "bytes" bytes iterating over the iovecs as necessary. Also, instead of only faulting in the first and last page of the range, all pages are faulted in. This function is needed by NTFS when it does multi page file writes. Signed-off-by: Anton Altaparmakov <anton@tuxera.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11drop bogus check in file_open_root()Al Viro1-3/+0
For one thing, LOOKUP_DIRECTORY will be dealt with in do_last(). For another, name can be an empty string, but not NULL - no callers pass that and it would oops immediately if they would. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11switch security_inode_getattr() to struct path *Al Viro10-35/+24
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11constify tomoyo_realpath_from_path()Al Viro2-4/+4
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11whack-a-mole: there's no point doing set_fs(USER_DS) in sigframe setupAl Viro6-21/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11whack-a-mole: no need to set_fs(USER_DS) in {start,flush}_thread()Al Viro6-8/+0
flush_old_exec() has already done that. Back on 2011 a bunch of instances like that had been kicked out, but that hadn't taken care of then-out-of-tree architectures, obviously, and they served as reinfection vector... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11remove incorrect comment in lookup_one_len()Al Viro1-3/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11namei.c: fold do_path_lookup() into both callersAl Viro1-24/+24
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-11kill struct filename.separateAl Viro2-14/+17
just make const char iname[] the last member and compare name->name with name->iname instead of checking name->separate We need to make sure that out-of-line name doesn't end up allocated adjacent to struct filename refering to it; fortunately, it's easy to achieve - just allocate that struct filename with one byte in ->iname[], so that ->iname[0] will be inside the same object and thus have an address different from that of out-of-line name [spotted by Boqun Feng <boqun.feng@gmail.com>] Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>