aboutsummaryrefslogtreecommitdiff
path: root/hw/9pfs
AgeCommit message (Collapse)AuthorFilesLines
2017-05-259pfs: local: metadata file for the VirtFS rootGreg Kurz1-27/+59
When using the mapped-file security, credentials are stored in a metadata directory located in the parent directory. This is okay for all paths with the notable exception of the root path, since we don't want and probably can't create a metadata directory above the virtfs directory on the host. This patch introduces a dedicated metadata file, sitting in the virtfs root for this purpose. It relies on the fact that the "." name necessarily refers to the virtfs root. As for the metadata directory, we don't want the client to see this file. The current code only cares for readdir() but there are many other places to fix actually. The filtering logic is hence put in a separate function. Before: # ls -ld drwxr-xr-x. 3 greg greg 4096 May 5 12:49 . # chown root.root . chown: changing ownership of '.': Is a directory # ls -ld drwxr-xr-x. 3 greg greg 4096 May 5 12:49 . After: # ls -ld drwxr-xr-x. 3 greg greg 4096 May 5 12:49 . # chown root.root . # ls -ld drwxr-xr-x. 3 root root 4096 May 5 12:50 . and from the host: ls -al .virtfs_metadata_root -rwx------. 1 greg greg 26 May 5 12:50 .virtfs_metadata_root $ cat .virtfs_metadata_root virtfs.uid=0 virtfs.gid=0 Reported-by: Leo Gaspard <leo@gaspard.io> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Leo Gaspard <leo@gaspard.io> [groug: work around a patchew false positive in local_set_mapped_file_attrat()]
2017-05-259pfs: local: simplify file openingGreg Kurz3-50/+29
The logic to open a path currently sits between local_open_nofollow() and the relative_openat_nofollow() helper, which has no other user. For the sake of clarity, this patch moves all the code of the helper into its unique caller. While here we also: - drop the code to skip leading "/" because the backend isn't supposed to pass anything but relative paths without consecutive slashes. The assert() is kept because we really don't want a buggy backend to pass an absolute path to openat(). - use strchrnul() to get a simpler code. This is ok since virtfs is for linux+glibc hosts only. - don't dup() the initial directory and add an assert() to ensure we don't return the global mountfd to the caller. BTW, this would mean that the caller passed an empty path, which isn't supposed to happen either. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> [groug: fixed typos in changelog]
2017-05-259pfs: local: resolve special directories in pathsGreg Kurz1-7/+25
When using the mapped-file security mode, the creds of a path /foo/bar are stored in the /foo/.virtfs_metadata/bar file. This is okay for all paths unless they end with '.' or '..', because we cannot create the corresponding file in the metadata directory. This patch ensures that '.' and '..' are resolved in all paths. The core code only passes path elements (no '/') to the backend, with the notable exception of the '/' path, which refers to the virtfs root. This patch preserves the current behavior of converting it to '.' so that it can be passed to "*at()" syscalls ('/' would mean the host root). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-05-259pfs: check return value of v9fs_co_name_to_path()Greg Kurz1-11/+25
These v9fs_co_name_to_path() call sites have always been around. I guess no care was taken to check the return value because the name_to_path operation could never fail at the time. This is no longer true: the handle and synth backends can already fail this operation, and so will the local backend soon. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-05-259pfs: assume utimensat() and futimens() are presentGreg Kurz1-5/+0
The utimensat() and futimens() syscalls have been around for ages (ie, glibc 2.6 and linux 2.6.22), and the decision was already taken to switch to utimensat() anyway when fixing CVE-2016-9602 in 2.9. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-05-259pfs: local: fix unlink of alien files in mapped-file modeGreg Kurz1-19/+15
When trying to remove a file from a directory, both created in non-mapped mode, the file remains and EBADF is returned to the guest. This is a regression introduced by commit "df4938a6651b 9pfs: local: unlinkat: don't follow symlinks" when fixing CVE-2016-9602. It changed the way we unlink the metadata file from ret = remove("$dir/.virtfs_metadata/$name"); if (ret < 0 && errno != ENOENT) { /* Error out */ } /* Ignore absence of metadata */ to fd = openat("$dir/.virtfs_metadata") unlinkat(fd, "$name") if (ret < 0 && errno != ENOENT) { /* Error out */ } /* Ignore absence of metadata */ If $dir was created in non-mapped mode, openat() fails with ENOENT and we pass -1 to unlinkat(), which fails in turn with EBADF. We just need to check the return of openat() and ignore ENOENT, in order to restore the behaviour we had with remove(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> [groug: rewrote the comments as suggested by Eric]
2017-05-259pfs: drop pdu_push_and_notify()Greg Kurz1-6/+1
Only pdu_complete() needs to notify the client that a request has completed. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-25virtio-9p/xen-9p: move 9p specific bits to core 9p codeGreg Kurz4-14/+10
These bits aren't related to the transport so let's move them to the core code. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-18Merge remote-tracking branch 'quintela/tags/migration/20170517' into stagingStefan Hajnoczi1-1/+1
migration/next for 20170517 # gpg: Signature made Wed 17 May 2017 11:46:36 AM BST # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * quintela/tags/migration/20170517: migration: Move check_migratable() into qdev.c migration: Move postcopy stuff to postcopy-ram.c migration: Move page_cache.c to migration/ migration: Create migration/blocker.h ram: Rename RAM_SAVE_FLAG_COMPRESS to RAM_SAVE_FLAG_ZERO migration: Pass Error ** argument to {save,load}_vmstate migration: Fix regression with compression threads Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-17migration: Create migration/blocker.hJuan Quintela1-1/+1
This allows us to remove lots of includes of migration/migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-16xen: call qemu_set_cloexec instead of fcntlStefano Stabellini1-1/+1
Use the common utility function, which contains checks on return values and first calls F_GETFD as recommended by POSIX.1-2001, instead of manually calling fcntl. CID: 1374831 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com CC: Eric Blake <eblake@redhat.com>
2017-05-16xen/9pfs: fix two resource leaks on error paths, discovered by CoverityStefano Stabellini1-0/+2
CID: 1374836 Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com
2017-05-159pfs: local: forbid client access to metadata (CVE-2017-7493)Greg Kurz1-2/+56
When using the mapped-file security mode, we shouldn't let the client mess with the metadata. The current code already tries to hide the metadata dir from the client by skipping it in local_readdir(). But the client can still access or modify it through several other operations. This can be used to escalate privileges in the guest. Affected backend operations are: - local_mknod() - local_mkdir() - local_open2() - local_symlink() - local_link() - local_unlinkat() - local_renameat() - local_rename() - local_name_to_path() Other operations are safe because they are only passed a fid path, which is computed internally in local_name_to_path(). This patch converts all the functions listed above to fail and return EINVAL when being passed the name of the metadata dir. This may look like a poor choice for errno, but there's no such thing as an illegal path name on Linux and I could not think of anything better. This fixes CVE-2017-7493. Reported-by: Leo Gaspard <leo@gaspard.io> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-26Merge remote-tracking branch 'remotes/sstabellini/tags/xen-20170421-v2-tag' ↵Peter Maydell5-5/+469
into staging Xen 2017/04/21 + fix # gpg: Signature made Tue 25 Apr 2017 19:10:37 BST # gpg: using RSA key 0x894F8F4870E1AE90 # gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>" # gpg: aka "Stefano Stabellini <sstabellini@kernel.org>" # Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90 * remotes/sstabellini/tags/xen-20170421-v2-tag: (21 commits) move xen-mapcache.c to hw/i386/xen/ move xen-hvm.c to hw/i386/xen/ move xen-common.c to hw/xen/ add xen-9p-backend to MAINTAINERS under Xen xen/9pfs: build and register Xen 9pfs backend xen/9pfs: send responses back to the frontend xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal xen/9pfs: receive requests from the frontend xen/9pfs: connect to the frontend xen/9pfs: introduce Xen 9pfs backend 9p: introduce a type for the 9p header xen: import ring.h from xen configure: use pkg-config for obtaining xen version xen: additionally restrict xenforeignmemory operations xen: use libxendevice model to restrict operations xen: use 5 digit xen versions xen: use libxendevicemodel when available configure: detect presence of libxendevicemodel xen: create wrappers for all other uses of xc_hvm_XXX() functions xen: rename xen_modified_memory() to xen_hvm_modified_memory() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-04-25xen/9pfs: build and register Xen 9pfs backendStefano Stabellini1-0/+1
Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-25xen/9pfs: send responses back to the frontendStefano Stabellini1-0/+19
Once a request is completed, xen_9pfs_push_and_notify gets called. In xen_9pfs_push_and_notify, update the indexes (data has already been copied to the sg by the common code) and send a notification to the frontend. Schedule the bottom-half to check if we already have any other requests pending. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-25xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshalStefano Stabellini1-2/+97
Implement xen_9pfs_init_in/out_iov_from_pdu and xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the data on the ring. This is safe as we only handle one request per ring at any given time. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-25xen/9pfs: receive requests from the frontendStefano Stabellini1-0/+50
Upon receiving an event channel notification from the frontend, schedule the bottom half. From the bottom half, read one request from the ring, create a pdu and call pdu_submit to handle it. For now, only handle one request per ring at a time. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-25xen/9pfs: connect to the frontendStefano Stabellini1-1/+181
Write the limits of the backend to xenstore. Connect to the frontend. Upon connection, allocate the rings according to the protocol specification. Initialize a QEMUBH to schedule work upon receiving an event channel notification from the frontend. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-25xen/9pfs: introduce Xen 9pfs backendStefano Stabellini2-0/+117
Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Greg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-219p: introduce a type for the 9p headerStefano Stabellini2-5/+7
Use the new type in virtio-9p-device. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
2017-04-189pfs: local: set the path of the export root to "."Greg Kurz1-1/+6
The local backend was recently converted to using "at*()" syscalls in order to ensure all accesses happen below the shared directory. This requires that we only pass relative paths, otherwise the dirfd argument to the "at*()" syscalls is ignored and the path is treated as an absolute path in the host. This is actually the case for paths in all fids, with the notable exception of the root fid, whose path is "/". This causes the following backend ops to act on the "/" directory of the host instead of the virtfs shared directory when the export root is involved: - lstat - chmod - chown - utimensat ie, chmod /9p_mount_point in the guest will be converted to chmod / in the host for example. This could cause security issues with a privileged QEMU. All "*at()" syscalls are being passed an open file descriptor. In the case of the export root, this file descriptor points to the path in the host that was passed to -fsdev. The fix is thus as simple as changing the path of the export root fid to be "." instead of "/". This is CVE-2017-7471. Cc: qemu-stable@nongnu.org Reported-by: Léo Gaspard <leo@gaspard.io> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-04-109pfs: xattr: fix memory leak in v9fs_list_xattrLi Qiang1-0/+1
Free 'orig_value' in error path. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-04-049pfs: clear migration blocker at session resetGreg Kurz1-5/+6
The migration blocker survives a device reset: if the guest mounts a 9p share and then gets rebooted with system_reset, it will be unmigratable until it remounts and umounts the 9p share again. This happens because the migration blocker is supposed to be cleared when we put the last reference on the root fid, but virtfs_reset() wrongly calls free_fid() instead of put_fid(). This patch fixes virtfs_reset() so that it honor the way fids are supposed to be manipulated: first get a reference and later put it back when you're done. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Li Qiang <liqiang6-s@360.cn>
2017-04-049pfs: fix multiple flush for same requestGreg Kurz1-2/+4
If a client tries to flush the same outstanding request several times, only the first flush completes. Subsequent ones keep waiting for the request completion in v9fs_flush() and, therefore, leak a PDU. This will cause QEMU to hang when draining active PDUs the next time the device is reset. Let have each flush request wake up the next one if any. The last waiter frees the cancelled PDU. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-279pfs: fix file descriptor leakLi Qiang1-0/+8
The v9fs_create() and v9fs_lcreate() functions are used to create a file on the backend and to associate it to a fid. The fid shouldn't be already in-use, otherwise both functions may silently leak a file descriptor or allocated memory. The current code doesn't check that. This patch ensures that the fid isn't already associated to anything before using it. Signed-off-by: Li Qiang <liqiang6-s@360.cn> (reworded the changelog, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-03-219pfs: proxy: assert if unmarshal failsGreg Kurz1-11/+11
Replies from the virtfs proxy are made up of a fixed-size header (8 bytes) and a payload of variable size (maximum 64kb). When receiving a reply, the proxy backend first reads the whole header and then unmarshals it. If the header is okay, it then does the same operation with the payload. Since the proxy backend uses a pre-allocated buffer which has enough room for a header and the maximum payload size, marshalling should never fail with fixed size arguments. Any error here is likely to result from a more serious corruption in QEMU and we'd better dump core right away. This patch adds error checks where they are missing and converts the associated error paths into assertions. This should also address Coverity's complaints CID 1348519 and CID 1348520, about not always checking the return value of proxy_unmarshal(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-03-219pfs: don't try to flush self and avoid QEMU hang on resetGreg Kurz1-4/+8
According to the 9P spec [*], when a client wants to cancel a pending I/O request identified by a given tag (uint16), it must send a Tflush message and wait for the server to respond with a Rflush message before reusing this tag for another I/O. The server may still send a completion message for the I/O if it wasn't actually cancelled but the Rflush message must arrive after that. QEMU hence waits for the flushed PDU to complete before sending the Rflush message back to the client. If a client sends 'Tflush tag oldtag' and tag == oldtag, QEMU will then allocate a PDU identified by tag, find it in the PDU list and wait for this same PDU to complete... i.e. wait for a completion that will never happen. This causes a tag and ring slot leak in the guest, and a PDU leak in QEMU, all of them limited by the maximal number of PDUs (128). But, worse, this causes QEMU to hang on device reset since v9fs_reset() wants to drain all pending I/O. This insane behavior is likely to denote a bug in the client, and it would deserve an Rerror message to be sent back. Unfortunately, the protocol allows it and requires all flush requests to suceed (only a Tflush response is expected). The only option is to detect when we have to handle a self-referencing flush request and report success to the client right away. [*] http://man.cat-v.org/plan_9/5/flush Reported-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-03-069pfs: fix vulnerability in openat_dir() and local_unlinkat_common()Greg Kurz2-2/+3
We should pass O_NOFOLLOW otherwise openat() will follow symlinks and make QEMU vulnerable. While here, we also fix local_unlinkat_common() to use openat_dir() for the same reasons (it was a leftover in the original patchset actually). This fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-069pfs: fix O_PATH build break with older glibc versionsGreg Kurz1-1/+6
When O_PATH is used with O_DIRECTORY, it only acts as an optimization: the openat() syscall simply finds the name in the VFS, and doesn't trigger the underlying filesystem. On systems that don't define O_PATH, because they have glibc version 2.13 or older for example, we can safely omit it. We don't want to deactivate O_PATH globally though, in case it is used without O_DIRECTORY. The is done with a dedicated macro. Systems without O_PATH may thus fail to resolve names that involve unreadable directories, compared to newer systems succeeding, but such corner case failure is our only option on those older systems to avoid the security hole of chasing symlinks inappropriately. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> (added last paragraph to changelog as suggested by Eric Blake) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-03-069pfs: don't use AT_EMPTY_PATH in local_set_cred_passthrough()Greg Kurz1-1/+1
The name argument can never be an empty string, and dirfd always point to the containing directory of the file name. AT_EMPTY_PATH is hence useless here. Also it breaks build with glibc version 2.13 and older. It is actually an oversight of a previous tentative patch to implement this function. We can safely drop it. Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Greg Kurz <groug@kaod.org> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-069pfs: fail local_statfs() earlierGreg Kurz1-0/+3
If we cannot open the given path, we can return right away instead of passing -1 to fstatfs() and close(). This will make Coverity happy. (Coverity issue CID1371729) Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel P. berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-03-069pfs: fix fd leak in local_opendir()Greg Kurz1-0/+1
Coverity issue CID1371731 Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-03-069pfs: fix bogus fd check in local_remove()Greg Kurz1-1/+1
This was spotted by Coverity as a fd leak. This is certainly true, but also local_remove() would always return without doing anything, unless the fd is zero, which is very unlikely. (Coverity issue CID1371732) Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-01Merge remote-tracking branch 'remotes/gkurz/tags/cve-2016-9602-for-upstream' ↵Peter Maydell9-596/+893
into staging This pull request have all the fixes for CVE-2016-9602, so that it can be easily picked up by downstreams, as suggested by Michel Tokarev. # gpg: Signature made Tue 28 Feb 2017 10:21:32 GMT # gpg: using DSA key 0x02FC3AEB0101DBC2 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" # gpg: aka "Greg Kurz <groug@free.fr>" # gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>" # gpg: aka "Gregory Kurz (Groug) <groug@free.fr>" # gpg: aka "[jpeg image of size 3330]" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2 * remotes/gkurz/tags/cve-2016-9602-for-upstream: (28 commits) 9pfs: local: drop unused code 9pfs: local: open2: don't follow symlinks 9pfs: local: mkdir: don't follow symlinks 9pfs: local: mknod: don't follow symlinks 9pfs: local: symlink: don't follow symlinks 9pfs: local: chown: don't follow symlinks 9pfs: local: chmod: don't follow symlinks 9pfs: local: link: don't follow symlinks 9pfs: local: improve error handling in link op 9pfs: local: rename: use renameat 9pfs: local: renameat: don't follow symlinks 9pfs: local: lstat: don't follow symlinks 9pfs: local: readlink: don't follow symlinks 9pfs: local: truncate: don't follow symlinks 9pfs: local: statfs: don't follow symlinks 9pfs: local: utimensat: don't follow symlinks 9pfs: local: remove: don't follow symlinks 9pfs: local: unlinkat: don't follow symlinks 9pfs: local: lremovexattr: don't follow symlinks 9pfs: local: lsetxattr: don't follow symlinks ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-289pfs: local: drop unused codeGreg Kurz1-198/+0
Now that the all callbacks have been converted to use "at" syscalls, we can drop this code. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: open2: don't follow symlinksGreg Kurz1-37/+19
The local_open2() callback is vulnerable to symlink attacks because it calls: (1) open() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one (4) local_post_create_passthrough() which calls in turn lchown() and chmod(), both functions also following symbolic links This patch converts local_open2() to rely on opendir_nofollow() and mkdirat() to fix (1), as well as local_set_xattrat(), local_set_mapped_file_attrat() and local_set_cred_passthrough() to fix (2), (3) and (4) respectively. Since local_open2() already opens a descriptor to the target file, local_set_cred_passthrough() is modified to reuse it instead of opening a new one. The mapped and mapped-file security modes are supposed to be identical, except for the place where credentials and file modes are stored. While here, we also make that explicit by sharing the call to openat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: mkdir: don't follow symlinksGreg Kurz1-35/+20
The local_mkdir() callback is vulnerable to symlink attacks because it calls: (1) mkdir() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one (4) local_post_create_passthrough() which calls in turn lchown() and chmod(), both functions also following symbolic links This patch converts local_mkdir() to rely on opendir_nofollow() and mkdirat() to fix (1), as well as local_set_xattrat(), local_set_mapped_file_attrat() and local_set_cred_passthrough() to fix (2), (3) and (4) respectively. The mapped and mapped-file security modes are supposed to be identical, except for the place where credentials and file modes are stored. While here, we also make that explicit by sharing the call to mkdirat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: mknod: don't follow symlinksGreg Kurz1-33/+35
The local_mknod() callback is vulnerable to symlink attacks because it calls: (1) mknod() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one (4) local_post_create_passthrough() which calls in turn lchown() and chmod(), both functions also following symbolic links This patch converts local_mknod() to rely on opendir_nofollow() and mknodat() to fix (1), as well as local_set_xattrat() and local_set_mapped_file_attrat() to fix (2) and (3) respectively. A new local_set_cred_passthrough() helper based on fchownat() and fchmodat_nofollow() is introduced as a replacement to local_post_create_passthrough() to fix (4). The mapped and mapped-file security modes are supposed to be identical, except for the place where credentials and file modes are stored. While here, we also make that explicit by sharing the call to mknodat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: symlink: don't follow symlinksGreg Kurz1-56/+25
The local_symlink() callback is vulnerable to symlink attacks because it calls: (1) symlink() which follows symbolic links for all path elements but the rightmost one (2) open(O_NOFOLLOW) which follows symbolic links for all path elements but the rightmost one (3) local_set_xattr()->setxattr() which follows symbolic links for all path elements (4) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one This patch converts local_symlink() to rely on opendir_nofollow() and symlinkat() to fix (1), openat(O_NOFOLLOW) to fix (2), as well as local_set_xattrat() and local_set_mapped_file_attrat() to fix (3) and (4) respectively. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: chown: don't follow symlinksGreg Kurz1-9/+17
The local_chown() callback is vulnerable to symlink attacks because it calls: (1) lchown() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one This patch converts local_chown() to rely on open_nofollow() and fchownat() to fix (1), as well as local_set_xattrat() and local_set_mapped_file_attrat() to fix (2) and (3) respectively. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: chmod: don't follow symlinksGreg Kurz1-11/+167
The local_chmod() callback is vulnerable to symlink attacks because it calls: (1) chmod() which follows symbolic links for all path elements (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen() and mkdir(), both functions following symbolic links for all path elements but the rightmost one We would need fchmodat() to implement AT_SYMLINK_NOFOLLOW to fix (1). This isn't the case on linux unfortunately: the kernel doesn't even have a flags argument to the syscall :-\ It is impossible to fix it in userspace in a race-free manner. This patch hence converts local_chmod() to rely on open_nofollow() and fchmod(). This fixes the vulnerability but introduces a limitation: the target file must readable and/or writable for the call to openat() to succeed. It introduces a local_set_xattrat() replacement to local_set_xattr() based on fsetxattrat() to fix (2), and a local_set_mapped_file_attrat() replacement to local_set_mapped_file_attr() based on local_fopenat() and mkdirat() to fix (3). No effort is made to factor out code because both local_set_xattr() and local_set_mapped_file_attr() will be dropped when all users have been converted to use the "at" versions. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: link: don't follow symlinksGreg Kurz1-29/+55
The local_link() callback is vulnerable to symlink attacks because it calls: (1) link() which follows symbolic links for all path elements but the rightmost one (2) local_create_mapped_attr_dir()->mkdir() which follows symbolic links for all path elements but the rightmost one This patch converts local_link() to rely on opendir_nofollow() and linkat() to fix (1), mkdirat() to fix (2). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: improve error handling in link opGreg Kurz1-11/+21
When using the mapped-file security model, we also have to create a link for the metadata file if it exists. In case of failure, we should rollback. That's what this patch does. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: rename: use renameatGreg Kurz1-30/+27
The local_rename() callback is vulnerable to symlink attacks because it uses rename() which follows symbolic links in all path elements but the rightmost one. This patch simply transforms local_rename() into a wrapper around local_renameat() which is symlink-attack safe. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: renameat: don't follow symlinksGreg Kurz1-10/+64
The local_renameat() callback is currently a wrapper around local_rename() which is vulnerable to symlink attacks. This patch rewrites local_renameat() to have its own implementation, based on local_opendir_nofollow() and renameat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: lstat: don't follow symlinksGreg Kurz1-17/+61
The local_lstat() callback is vulnerable to symlink attacks because it calls: (1) lstat() which follows symbolic links in all path elements but the rightmost one (2) getxattr() which follows symbolic links in all path elements (3) local_mapped_file_attr()->local_fopen()->openat(O_NOFOLLOW) which follows symbolic links in all path elements but the rightmost one This patch converts local_lstat() to rely on opendir_nofollow() and fstatat(AT_SYMLINK_NOFOLLOW) to fix (1), fgetxattrat_nofollow() to fix (2). A new local_fopenat() helper is introduced as a replacement to local_fopen() to fix (3). No effort is made to factor out code because local_fopen() will be dropped when all users have been converted to call local_fopenat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: readlink: don't follow symlinksGreg Kurz1-9/+17
The local_readlink() callback is vulnerable to symlink attacks because it calls: (1) open(O_NOFOLLOW) which follows symbolic links for all path elements but the rightmost one (2) readlink() which follows symbolic links for all path elements but the rightmost one This patch converts local_readlink() to rely on open_nofollow() to fix (1) and opendir_nofollow(), readlinkat() to fix (2). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: truncate: don't follow symlinksGreg Kurz1-6/+7
The local_truncate() callback is vulnerable to symlink attacks because it calls truncate() which follows symbolic links in all path elements. This patch converts local_truncate() to rely on open_nofollow() and ftruncate() instead. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: statfs: don't follow symlinksGreg Kurz1-6/+4
The local_statfs() callback is vulnerable to symlink attacks because it calls statfs() which follows symbolic links in all path elements. This patch converts local_statfs() to rely on open_nofollow() and fstatfs() instead. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>