Previously, fuse-overlayfs always used user.fuseoverlayfs.override_stat
for the upper layer while honoring user.containers.override_stat for
lower layers so that it can consume a layer created by
containers/storage.
It turned out that containers/storage also needs to get the overriding
extended attribute set by fuse-overlayfs and to set one for the upper
layer to make the root directory of the upper layer inherit the mode
of a lower layer. Adding code to get and to set
user.fuseoverlayfs.override_stat to containers/storage is a bit ugly.
The underlying problem is that fuse-overlayfs changes what name to use
ad hoc. Fix it by always preferring user.containers.override_stat, which
containers/storage honors, over user.fuseoverlayfs.overlayfs, which is
specific to fuse-overlayfs.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
ovl_setattr () used to pass -1 as uid or gid when either of them
is not changed for do_fchown () / do_chown (), but if these functions
use overriding xattrs instead of real fchown () or chown (), it causes
-1 to be written in owner overriding xattrs and break them.
Replace -1 with the current uid or gid before calling do_fchown () /
do_chown ().
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
do_fchmod () and do_chmod () used to call override_mode () directly to
retrieve the owner information, but the usage of override_mode () was
wrong; override_mode () expects struct stat is already populated by
the information provided by the underlying filesystem, but do_fchmod ()
and do_chmod () only zeroed st_uid and st_gid. override_mode () does not
update the owner information when st_mode is not S_IFDIR nor S_IFREG so
this caused chmod to change the file owner to root at random.
Use the logic rpl_stat () employs to file owner retrieval for chmod
functions to ensure they provide the owner information consistent with
rpl_stat ().
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
override_mode () used to suppress ENODATA only in a certain condition.
ENODATA errors in other situations made load_dir () fail because it
indirectly calls override_mode () when the underlying file system
reports DT_UNKNOWN for an opaque whiteout file and such an file does
not have mode xattrs. do_fchmod () and do_chmod () worked around the
problem by supressing ENODATA by themselves, but that led to code
duplication. Always suppress ENODATA to resolve these problems.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
The test of fast_ino_check used CentOS Stream 8, which is no longer
supported and whose repositories are no longer available.
While we can update it to use CentOS Stream 9, use Fedora instead for
consistency with the other test cases.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
The test case for https://github.com/containers/fuse-overlayfs/issues/86
does no longer work because it relies on CentOS Stream 8 repositories,
which are unavailable.
While we can update it to use CentOS Stream 9, the issue says it is
limited to CentOS 6, and it is unclear if the test case will reproduce
the intended scenario with CentOS Stream 8 or 9 so drop it.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
if xattrs permissions are used, create the directory in two steps and
set the correct ownership before moving it into the target.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
cache the number of links for a directory instead of calculating it on
every stat. It makes a huge difference when the directory has a lot
of entries.
Closes: https://github.com/containers/fuse-overlayfs/issues/401
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
fix the check for writeable /proc to use statfs instead of statvfs,
and use the unitialized statvfs structure to check for the writeable
bit.
Closes: https://github.com/containers/fuse-overlayfs/issues/397
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
