If the call to `get_upper_layer(lo)` returns `NULL` then the
`node->layer` will be `NULL`, too. If this is the case we pass `NULL` to
`direct_fsync()` which will cause a segmentation fault in:
```c
cfd = openat(l->fd, path, O_NOFOLLOW|O_DIRECTORY);
```
To fix this we now apply an additional check and error in the case of
`get_upper_layer(lo) == NULL`.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
use the full relative path when looking up the whiteout file,
otherwise a whiteout in the upper layer will hide files in
subdirectories.
Closes: https://github.com/containers/fuse-overlayfs/issues/151
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
if no -o plugins is specified, load them from $PKGLIBEXECDIR (usually
has the value /usr/libexec/fuse-overlayfs).
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Add a simple plugin mechanism that will help to expand fuse-overlayfs
functionalities, in particular it allows to load data from a layer on
demand.
A plugin is loaded into fuse-overlayfs using the option:
-o plugins=path/to/plugin.so:path/to/another/plugin.so
A layer can use a plugin with the syntax:
-o lowerdir=//plugin-name/DATA-FOR-THE-PLUGIN/path
Each time a file/directory is looked up, if a plugin is registered for
a layer, the plugin is first notified about the request.
After the callback is invoked, fuse-overlayfs still expects the data
to be accessible at the specified directory.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
if the file is present only on the upper layer, do not create a
whiteout when it is created. Previously it was looking only at the
parent directory.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
fix the lookup function to report also a whiteout node, instead of
NULL. This is required to correctly delete the whiteout file when it
exists.
Closes: https://github.com/containers/fuse-overlayfs/issues/122
Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
It's perfectly possible to set attributes by being the file's owner; one
does not need write access to the contents.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
correctly read the inode when processing a UNIX socket.
regression introduced by b25bbde64dc5d06373e087d7fae6367acf1fd09e.
Closes: https://github.com/containers/fuse-overlayfs/issues/110
Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
introduce a hash map to refer from an inode to the file paths.
A recent change where we enable FUSE writeback by default uncovered an
underlying issue in fuse-overlayfs where changes to a file with
multiple links would not be visible from the other link.
For each inode, maintain a list of nodes that refer to it, so that we
can still access it when a link is removed and more importantly we can
use the inode value with FUSE.
Closes: https://github.com/containers/fuse-overlayfs/issues/108
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1744109
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
when reading xattr, if the path cannot be open as it is a directory,
operate on the /proc/fd/FD path.
Closes: https://github.com/containers/fuse-overlayfs/issues/104
Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
node already keeps st_mode in cache so there is no need of the
additional stat to find out the file type.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
always use the /proc/self/fd/FD path when the path doesn't refer to a
directory or regular file.
commit 0b0c7a3a01dae4de65ba79016a111d794c1d1719 introduced the
regression.
Closes: https://github.com/containers/fuse-overlayfs/issues/99
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
