267fcadf | 06-Nov-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: fix v9fs_mark_fids_unreclaim() return value
The return value of v9fs_mark_fids_unreclaim() is then propagated to pdu_complete(). It should be a negative errno, not -1.
Signed-off-by: Greg Kur
9pfs: fix v9fs_mark_fids_unreclaim() return value
The return value of v9fs_mark_fids_unreclaim() is then propagated to pdu_complete(). It should be a negative errno, not -1.
Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
show more ...
|
772a7369 | 20-Sep-2017 |
Jan Dakinevich <jan.dakinevich@gmail.com> |
9pfs: check the size of transport buffer before marshaling
v9fs_do_readdir_with_stat() should check for a maximum buffer size before an attempt to marshal gathered data. Otherwise, buffers assumed a
9pfs: check the size of transport buffer before marshaling
v9fs_do_readdir_with_stat() should check for a maximum buffer size before an attempt to marshal gathered data. Otherwise, buffers assumed as misconfigured and the transport would be broken.
The patch brings v9fs_do_readdir_with_stat() in conformity with v9fs_do_readdir() behavior.
Signed-off-by: Jan Dakinevich <jan.dakinevich@gmail.com> [groug, regression caused my commit 8d37de41cab1 # 2.10] Signed-off-by: Greg Kurz <groug@kaod.org>
show more ...
|
4d8bc733 | 20-Sep-2017 |
Jan Dakinevich <jan.dakinevich@gmail.com> |
9pfs: fix name_to_path assertion in v9fs_complete_rename()
The third parameter of v9fs_co_name_to_path() must not contain `/' character.
The issue is most likely related to 9p2000.u protocol only.
9pfs: fix name_to_path assertion in v9fs_complete_rename()
The third parameter of v9fs_co_name_to_path() must not contain `/' character.
The issue is most likely related to 9p2000.u protocol only.
Signed-off-by: Jan Dakinevich <jan.dakinevich@gmail.com> [groug, regression caused by commit f57f5878578a # 2.10] Signed-off-by: Greg Kurz <groug@kaod.org>
show more ...
|
aa5e85a1 | 04-Sep-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: local: clarify fchmodat_nofollow() implementation
Since fchmodat(2) on Linux doesn't support AT_SYMLINK_NOFOLLOW, we have to implement it using workarounds. There are two different ways, depen
9pfs: local: clarify fchmodat_nofollow() implementation
Since fchmodat(2) on Linux doesn't support AT_SYMLINK_NOFOLLOW, we have to implement it using workarounds. There are two different ways, depending on whether the system supports O_PATH or not.
In the case O_PATH is supported, we rely on the behavhior of openat(2) when passing O_NOFOLLOW | O_PATH and the file is a symbolic link. Even if openat_file() already adds O_NOFOLLOW to the flags, this patch makes it explicit that we need both creation flags to obtain the expected behavior.
This is only cleanup, no functional change.
Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
06a37db7 | 29-Jun-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: handle transport errors in pdu_complete()
Contrary to what is written in the comment, a buggy guest can misconfigure the transport buffers and pdu_marshal() may return an error. If this ever
9pfs: handle transport errors in pdu_complete()
Contrary to what is written in the comment, a buggy guest can misconfigure the transport buffers and pdu_marshal() may return an error. If this ever happens, it is up to the transport layer to handle the situation (9P is transport agnostic).
This fixes Coverity issue CID1348518.
Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
show more ...
|
e08d1e11 | 29-Jun-2017 |
Stefano Stabellini <sstabellini@kernel.org> |
xen-9pfs: disconnect if buffers are misconfigured
Implement xen_9pfs_disconnect by unbinding the event channels. On xen_9pfs_free, call disconnect if any event channels haven't been disconnected.
I
xen-9pfs: disconnect if buffers are misconfigured
Implement xen_9pfs_disconnect by unbinding the event channels. On xen_9pfs_free, call disconnect if any event channels haven't been disconnected.
If the frontend misconfigured the buffers set the backend to "Closing" and disconnect it. Misconfigurations include requesting a read of more bytes than available on the ring buffer, or claiming to be writing more data than available on the ring buffer.
Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Signed-off-by: Greg Kurz <groug@kaod.org>
show more ...
|
8d37de41 | 29-Jun-2017 |
Greg Kurz <groug@kaod.org> |
virtio-9p: break device if buffers are misconfigured
The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device.
Signe
virtio-9p: break device if buffers are misconfigured
The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device.
Signed-off-by: Greg Kurz <groug@kaod.org>
show more ...
|
a4d99854 | 29-Jun-2017 |
Greg Kurz <groug@kaod.org> |
virtio-9p: message header is 7-byte long
The 9p spec at http://man.cat-v.org/plan_9/5/intro reads:
"Each 9P message begins with a four-byte size field specify- ing the length in bytes of the com
virtio-9p: message header is 7-byte long
The 9p spec at http://man.cat-v.org/plan_9/5/intro reads:
"Each 9P message begins with a four-byte size field specify- ing the length in bytes of the complete message including the four bytes of the size field itself. The next byte is the message type, one of the constants in the enumeration in the include file <fcall.h>. The next two bytes are an iden- tifying tag, described below."
ie, each message starts with a 7-byte long header.
The core 9P code already assumes this pretty much everywhere. This patch does the following: - makes the assumption explicit in the common 9p.h header, since it isn't related to the transport - open codes the header size in handle_9p_output() and hardens the sanity check on the space needed for the reply message
Signed-off-by: Greg Kurz <groug@kaod.org> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
show more ...
|
3a21fb2a | 29-Jun-2017 |
Greg Kurz <groug@kaod.org> |
virtio-9p: record element after sanity checks
If the guest sends a malformed request, we end up with a dangling pointer in V9fsVirtioState. This doesn't seem to cause any bug, but let's remove this
virtio-9p: record element after sanity checks
If the guest sends a malformed request, we end up with a dangling pointer in V9fsVirtioState. This doesn't seem to cause any bug, but let's remove this side effect anyway.
Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
453a1b23 | 29-Jun-2017 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
9pfs: replace g_malloc()+memcpy() with g_memdup()
I found these pattern via grepping the source tree. I don't have a coccinelle script for it!
Signed-off-by: Marc-André Lureau <marcandre.lureau@red
9pfs: replace g_malloc()+memcpy() with g_memdup()
I found these pattern via grepping the source tree. I don't have a coccinelle script for it!
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
show more ...
|
b96feb2c | 29-Jun-2017 |
Tobias Schramm <tobleminer@gmail.com> |
9pfs: local: Add support for custom fmode/dmode in 9ps mapped security modes
In mapped security modes, files are created with very restrictive permissions (600 for files and 700 for directories). Th
9pfs: local: Add support for custom fmode/dmode in 9ps mapped security modes
In mapped security modes, files are created with very restrictive permissions (600 for files and 700 for directories). This makes file sharing between virtual machines and users on the host rather complicated. Imagine eg. a group of users that need to access data produced by processes on a virtual machine. Giving those users access to the data will be difficult since the group access mode is always 0.
This patch makes the default mode for both files and directories configurable. Existing setups that don't know about the new parameters keep using the current secure behavior.
Signed-off-by: Tobias Schramm <tobleminer@gmail.com> Signed-off-by: Greg Kurz <groug@kaod.org>
show more ...
|
81ffbf5a | 25-May-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: local: metadata file for the VirtFS root
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 th
9pfs: local: metadata file for the VirtFS root
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()]
show more ...
|
3dbcf273 | 25-May-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: local: simplify file opening
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,
9pfs: local: simplify file opening
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]
show more ...
|
f57f5878 | 25-May-2017 |
Greg Kurz <groug@kaod.org> |
9pfs: local: resolve special directories in paths
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
9pfs: local: resolve special directories in paths
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>
show more ...
|