The explicit resolution of the upper directory path using `realpath()`
is not required before passing it to `read_dirs` since
`direct_load_data_source()` already does it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
The major use case of stat override is to enable rootless containers
on network filesystems, and they also lack security xattr support in
non-root user namespaces. Trying to set security xattrs on them result
in ENOTSUP and break things.
It makes little sense to share security xattrs with the underlying
filesystems when overriding stat in the first place. Linux's NFS server
exposes security xattrs only when the user explicitly claims the
security consistencies between the server and clients, and hide them
otherwise. Following this precedent, we should isolate security xattrs
since we know the security policy enforced by fuse-overlayfs is already
distinct from the underlying filesystem when overriding owners and file
mode.
Mark security xattrs inaccessible with STAT_OVERRIDE_CONTAINERS to
prefix all access to them with XATTR_CONTAINERS_OVERRIDE_PREFIX.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
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>
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>
- Create source whiteout only when needed
- Fix missing source whiteout when destination is whiteout
- Try the EXCHANGE trick also when NOREPLACE is set
Signed-off-by: Tuupertunut <tuupertunut@outlook.com>
Set correct value of RENAME_NOREPLACE when RENAME_EXCHANGE is not
already defined i.e use `1 << 0` instead of `1 << 2` which seems
incorrect.
Reference: f2906aa863/include/uapi/linux/fs.h (L50-L52)
Signed-off-by: Aditya R <arajan@redhat.com>
the kernel returns EOVERFLOW if the rootid cannot be mapped in the
current user namespace when reading the file capabilities
(security.capabilities xattr).
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
native overlay uses user.overlay to store the overlay metadata instead
of trusted.overlay, let's honor it as well.
Closes: https://github.com/containers/fuse-overlayfs/issues/328
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
fix the check for FUSE_CAP_POSIX_ACL. commit
0a659e75ef61456bda1fa4b0b30117296f66f4fe introduced the issue.
It is needed to run fuse-overlayfs on RHEL 7 kernels.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
If a dir is opaque, there's no need to create a whiteout within it as
the opacity will block out any files from lower dirs already anyways.
The kernel's overlay implementation also doesn't currently handle
whiteouts in opaque dirs very well (the whiteout shows up in readdir
calls but can't be stat'd), so this fix also improves compatibility
between fuse-overlay and the kernel's overlay a bit too.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>