Fix returning d_ino and d_type by readdir(3) in non-plus mode
When not using the readdir_plus mode, the d_type was not returned,
and the use_ino flag was not used for returning d_ino.
This patch fixes the returned values for d_ino and d_type by readdir(3)
The test for the returned value of d_ino has been adjusted to also
take the d_type into consideration and to check the returned values in
both basic readdir and readdir_plus modes. This is done by executing
the passthrough test twice.
Co-authored-by: Jean-Pierre André <jpandre@users.sourceforge.net>
Martin Pärtel [Wed, 3 Feb 2021 09:53:21 +0000 (11:53 +0200)]
Fix returning inode numbers from readdir() in offset==0 mode. (#584)
- Test added for all passthrough examples.
- passthrough.c uses offset==0 mode. The others don't.
- passthrough.c changed to set FUSE_FILL_DIR_PLUS to make the test pass.
- This fixes #583.
Stephen Kitt [Thu, 28 Jan 2021 21:51:10 +0000 (22:51 +0100)]
Ignore "-o nonempty" (#582)
Commit 0bef21e8543d removed "-o nonempty" since mounting over
non-empty directories is always allowed. But this broke tools which
specify "-o nonempty". Since the expected behaviour is the same
anyway, ignoring the "nonempty" option seems safe, and allows programs
specifying "-o nonempty" to continue working with fusermount3.
fusermount: Check for argv[0] being present (#577)
It is perfectly legal to execute a program with argc == 0 and therefore
no argv.
fusermount needs to check for this case, otherwise it will pass a NULL
poiunter to strdup() and cause undefined behavior.
Especially since fusermount is setuid root, we need to extra be careful.
Signed-off-by: Richard Weinberger <richard@nod.at>
Sargun Dhillon [Sun, 27 Dec 2020 11:17:46 +0000 (03:17 -0800)]
util/fusermount.c: Assume the kernel supports UMOUNT_NOFOLLOW (#574)
UMOUNT_NOFOLLOW was added in Kernel 2.6.34. It's been 10 years since it's been added
Kernel 5.9, and 5.10 break this check mechanism[1]. Let's deprecate it.
Zhiqiang Liu [Wed, 11 Nov 2020 02:00:23 +0000 (10:00 +0800)]
buffer.c: correct return value when buf is NULL
In commit d614415a ("buffer.c: check whether buf is
NULL in fuse_bufvec_advance func"), if fuse_bufvec_current
func returns NULL, it returns 1 directly. Actually,
we should return 0 when buf is NULL.
Fixes: d614415a ("buffer.c: check whether buf is NULL in fuse_bufvec_advance func") Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com> Signed-off-by: Haotian Li <lihaotian9@huawei.com>
Zhiqiang Liu [Thu, 5 Nov 2020 09:24:12 +0000 (17:24 +0800)]
mount.fuse.c: fix potential memory leak in main func
In mount.fuse.c, there are several memory leak problems in
main func. For example, setuid_name is allocated by calling
xstrdup func, however it is not freed before calling execl func.
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com> Signed-off-by: Haotian Li <lihaotian9@huawei.com>
In mount.fuse.c, pwd is set by calling getpwnam func.
If the matching entry is not found or an error occurs in
getpwnam func, pwd will be NULL. So we need to check
whether pwd is NULL before accessing it.
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com> Signed-off-by: Haotian Li <lihaotian9@huawei.com>
Allow caching symlinks in kernel page cache. (#551)
This commit defines a new capability called `FUSE_CAP_CACHE_SYMLINKS`.
It is off by default but you can now enable it by setting this flag in
in the `want` field of the `fuse_conn_info` structure.
When enabled, the kernel will save symlinks in its page cache,
by making use of the feature introduced in kernel 4.20:
https://github.com/torvalds/linux/commit/5571f1e65486be025f73fa6aa30fb03725d362a2
asafkahlon [Sun, 9 Aug 2020 11:37:26 +0000 (14:37 +0300)]
Define fuse_session_loop_mt as a macro on uclibc and MacOS (#532)
On uclibc and MacOS we don't use versioned symbols. Hence,
there's no definition for fuse_session_loop_mt on those cases
and the linker won't be able to resolve calls to fuse_session_loop_mt()
setlocale() can fail, returning NULL, if the user has an invalid (or
missing) locale set in the LANG environment variable.
In my case, this happens when using VS Code's integrated terminal to
launch a fuse-based filesystem. A bug (fix upcoming) results in VS Code
setting an invalid locale.
iconv_help() currently passes the return value of setlocale(...)
directly to strdup() without checking if it is NULL, resulting in a
crash.
To reproduce, simply set LANG="something_invalid" and call
fuse_lib_help().
Stack trace when the process receives `SIGSEGV`:
(gdb) bt
#0 0x00007fabd0fcc4b5 in __strlen_avx2 () from /usr/lib/libc.so.6
#1 0x00007fabd0ef9233 in strdup () from /usr/lib/libc.so.6
#2 0x00007fabd13b8128 in iconv_help () at ../lib/modules/iconv.c:641
#3 0x00007fabd13b81a8 in iconv_opt_proc (data=0x55580a6ee850, arg=0x55580a6edfb0 "-h", key=0, outargs=0x7ffeeb1a8ec8) at ../lib/modules/iconv.c:658
#4 0x00007fabd13af7d5 in call_proc (ctx=0x7ffeeb1a8ea0, arg=0x55580a6edfb0 "-h", key=0, iso=0) at ../lib/fuse_opt.c:161
#5 0x00007fabd13afaf1 in process_opt (ctx=0x7ffeeb1a8ea0, opt=0x7fabd13c3d40 <iconv_opts>, sep=0, arg=0x55580a6edfb0 "-h", iso=0) at ../lib/fuse_opt.c:233
#6 0x00007fabd13afd5a in process_gopt (ctx=0x7ffeeb1a8ea0, arg=0x55580a6edfb0 "-h", iso=0) at ../lib/fuse_opt.c:285
#7 0x00007fabd13b0117 in process_one (ctx=0x7ffeeb1a8ea0, arg=0x55580a6edfb0 "-h") at ../lib/fuse_opt.c:368
#8 0x00007fabd13b0190 in opt_parse (ctx=0x7ffeeb1a8ea0) at ../lib/fuse_opt.c:379
#9 0x00007fabd13b03d3 in fuse_opt_parse (args=0x7ffeeb1a8f70, data=0x55580a6ee850, opts=0x7fabd13c3d40 <iconv_opts>, proc=0x7fabd13b8186 <iconv_opt_proc>)
at ../lib/fuse_opt.c:414
#10 0x00007fabd13b8226 in iconv_new (args=0x7ffeeb1a8f70, next=0x0) at ../lib/modules/iconv.c:680
#11 0x00007fabd13a5627 in print_module_help (name=0x7fabd13b9e1c "iconv", fac=0x7fabd13d48e0 <fuse_module_iconv_factory>) at ../lib/fuse.c:4692
#12 0x00007fabd13a56aa in fuse_lib_help (args=0x7ffeeb1a9238) at ../lib/fuse.c:4721
iconv_help() is modified to print an error when setlocale() fails.
It then carries on printing the iconv module's help.
Reading setlocale(3), it seems that the strdup() of the result was
not necessary.
Miklos Szeredi [Thu, 14 May 2020 19:17:50 +0000 (21:17 +0200)]
passthrough_ll: remove symlink fallbacks (#514)
* passthrough_ll/hp: remove symlink fallbacks
Path lookup in the kernel has special rules for looking up magic symlinks
under /proc. If a filesystem operation is instructed to follow symlinks
(e.g. via AT_SYMLINK_FOLLOW or lack of AT_SYMLINK_NOFOLLOW), and the final
component is such a proc symlink, then the target of the magic symlink is
used for the operation, even if the target itself is a symlink. I.e. path
lookup is always terminated after following a final magic symlink.
I was erronously assuming that in the above case the target symlink would
also be followed, and so workarounds were added for a couple of operations
to handle the symlink case. Since the symlink can be handled simply by
following the proc symlink, these workardouds are not needed.
Jean-Yves VET [Fri, 13 Mar 2020 19:02:41 +0000 (20:02 +0100)]
Fix issue preventing using splice with reads (#505)
Context: SPLICE_WRITE is not used with regular buffers
(i.e. when they are not file-descriptor backed buffers).
There is a bug which assumes file descriptors are used.
If the amount of data associated with those FD is lower
than twice the page size, SPLICE_WRITE is not utilized.
With regular buffers the aggregated size was always 0.
Because vmsplice (splice user pages to/from a pipe) is
called before splice in fuse_lowlevel.c, regular buffers
would also work with splice.
This patch prevents to fallback to non-splice enabled
copies when itheir is no FD involved.
philmd [Mon, 24 Feb 2020 21:41:28 +0000 (22:41 +0100)]
Travis-CI: Fix ImportError: No module named 'zipp' (#502)
Upgrade pip to fix [*]:
[66/66] Linking target example/passthrough_hp.
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 174, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.5/runpy.py", line 133, in _get_module_details
return _get_module_details(pkg_main_name, error)
File "/usr/lib/python3.5/runpy.py", line 109, in _get_module_details
__import__(pkg_name)
File "/usr/local/lib/python3.5/dist-packages/pytest/__init__.py", line 6, in <module>
from _pytest.assertion import register_assert_rewrite
File "/usr/local/lib/python3.5/dist-packages/_pytest/assertion/__init__.py", line 7, in <module>
from _pytest.assertion import rewrite
File "/usr/local/lib/python3.5/dist-packages/_pytest/assertion/rewrite.py", line 24, in <module>
from _pytest.assertion import util
File "/usr/local/lib/python3.5/dist-packages/_pytest/assertion/util.py", line 14, in <module>
import _pytest._code
File "/usr/local/lib/python3.5/dist-packages/_pytest/_code/__init__.py", line 2, in <module>
from .code import Code # noqa
File "/usr/local/lib/python3.5/dist-packages/_pytest/_code/code.py", line 28, in <module>
import pluggy
File "/usr/local/lib/python3.5/dist-packages/pluggy/__init__.py", line 16, in <module>
from .manager import PluginManager, PluginValidationError
File "/usr/local/lib/python3.5/dist-packages/pluggy/manager.py", line 11, in <module>
import importlib_metadata
File "/usr/local/lib/python3.5/dist-packages/importlib_metadata/__init__.py", line 9, in <module>
import zipp
ImportError: No module named 'zipp'
The command "test/travis-build.sh" exited with 1.
Florian Weimer [Fri, 31 Jan 2020 18:38:41 +0000 (19:38 +0100)]
Update comment for the copy_file_range operation (#497)
copy_file_range was first implemented with copy-based emulation in
glibc 2.27, but the emulation was subsequently removed again because
correct emulation depends on why the application attempted to make a
copy. Therefore, file systems cannot rely on low-level userspace
performing emulation.
Anthony Rebello [Sat, 25 Jan 2020 10:17:09 +0000 (04:17 -0600)]
Fixes 477, optional src_dir in tst_(rmdir,unlink) (#493)
tst_rmdir and tst_unlink now pass for passthrough_hp.
Previously, tst_rmdir and tst_unlink created the directory / file
using src_dir, causing the test to fail as the cache was stale.
Now, the src_dir is optional. When cache is enabled, tst_rmdir
and tst_unlink do not provide a src_dir, forcing the test to
use mnt_dir itself.
Since keep_cache(FOPEN_KEEP_CACHE) has no effect for directory as
described in fuse_common.h, use cache_readdir(FOPEN_CACHE_DIR) for
diretory open when cache=always mode.
passthrough_ll: pass correct errno to fuse_reply_err()
fuse_reply_err() expects the error code, not its negative.
Upstreamed from https://www.redhat.com/archives/virtio-fs/2020-January/msg00000.html. Original commit message:
lo_copy_file_range() passes -errno to fuse_reply_err() and then fuse_reply_err()
changes it to errno again, so that subsequent fuse_send_reply_iov_nofree() catches
the wrong errno.(i.e. reports "fuse: bad error value: ...").
Make fuse_send_reply_iov_nofree() accept the correct -errno by passing errno
directly in lo_copy_file_range().
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com> Reviewed-by: Eryu Guan <eguan@linux.alibaba.com> Co-authored-by: Xiao Yang <ice_yangxiao@163.com>
Make ioctl prototype conditional on FUSE_USE_VERSION. (#482)
Define FUSE_USE_VERSION < 35 to get old ioctl prototype
with int commands; define FUSE_USE_VERSION >= 35 to get
new ioctl prototype with unsigned int commands.
Alan Somers [Sun, 3 Nov 2019 09:44:12 +0000 (02:44 -0700)]
Use the -o intr mount option on FreeBSD (#462)
FUSE file systems normally indicate their interruptibility by returning
ENOSYS to the first FUSE_INTERRUPT operation. But that causes two
problems for file systems that aren't interruptible:
1) A process may block on a signal, even if another thread could've
handled the signal. The kernel must know whether the FUSE thread is
interruptible before deciding which thread should receive a signal.
2) The protocol allows a FUSE daemon to simply ignore FUSE_INTERRUPT
operations. From the kernel's point of view, that is indistinguishable
from a FUSE_INTERRUPT operation arriving after the original operation
had already completed. Thus, the kernel can't interpret an ignored
FUSE_INTERRUPT as an indication that the daemon is non-interruptible.
With the -o nointr mount option, no FUSE_INTERRUPT operations will ever
be sent. Most FUSE file systems should require no modifications to take
advantage of this mount option.
Stefan Hajnoczi [Sun, 3 Nov 2019 09:43:43 +0000 (10:43 +0100)]
passthrough_ll: drop lo_dirp->fd field (#464)
fdopendir(3) takes ownership of the file descriptor. The presence of
the lo_dirp->fd field could lead to someone incorrectly adding a
close(d->fd) cleanup call in the future.
Do not store the file descriptor in struct lo_dirp since it is unused.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>