Fix n_xid_map leaks on error path and remove useless exit_code.
Fixes: 6e1726f8 ("userns: set uid and gid before entering into userns")
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
The helper function removes code duplication from tests that want to
initialize unix socket address to an absolute file path, derived from
current working directory of the test + relative filename of a resulting
socket. Because the former code used cwd = get_current_dir_name() as
part of absolute filename generation, the resulting filepath could later
cause failure of bind systcall due to unchecked permissions and
introduce confusing permission errors.
Signed-off-by: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
Any filesystem syscall, that needs to navigate to inode by it's
absolute path performs successive lookup operations for each part of the
path. Lookup operation includes access rights check.
Usually but not always zdtm tests processes fall under 'other' access
category. Also, usually directories don't have 'x' bit set for other.
In case when bit 'x' is not set and user-ID and group-ID of a process
relate it to 'other', test's will not succeed in performing these
syscalls which are most of filesystem api, that has const char *path
as part of it arguments (open, openat, mkdir, bind, etc).
The observable behavior of that is that zdtm tests fail at file
creation ops on one system and pass on the other. The above is not
immediately clear to the developer by just looking at failed test's logs.
Investigation of that is also not quick for a developer due to the
complex structure of zdtm runtime where nested clones with
NAMESPACE flags take place alongside with bind-mounts.
As an additional note: 'get_current_dir_name' is documented as returning
EACCESS in case when some part of the path lacks read/list permissions.
But in fact it's not always so. Practice shows, that test processes can
get false success on this operation only to fail on later call to
something like mkdir/mknod/bind with a given path in arguments.
'get_cwd_check_perm' is a wrapper around 'get_current_dir_name'. It also
checks for permissions on the given filepath and logs the error. This
directs the developer towards the right investigation path or even
eliminates the need for investigation completely.
Signed-off-by: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
Here is a fast path when two consequent vma-s share the same file.
But one of these vma-s can map a file with MAP_SHARED, but another one
can map it with MAP_PRIVATE and we need to take this into account.
Any shared memroy mapping can be opened via /proc/self/maps_files/.
Such file descriptors look like memfd file descriptors, so
they can be dumped by the same way.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
The config.h detection scripts should use the provided CFLAGS/LDFLAGS
as it tries to link libnl, libnet, and others.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
We should ignore (not parse) images that has non-crtool format,
that images has no magic number (RAW_IMAGE_MAGIC equals 0).
nftables images has format compatible with `nft -f /proc/self/fd/0`
input format.
Reported-by: Mr Jenkins
Signed-off-by: Alexander Mikhalitsyn (Virtuozzo) <alexander@mihalicyn.com>
The file only includes other headers (which may be not needed).
If we aim for one-include-for-compel, we could instead paste all
subheaders into "compel.h".
Rather, I think it's worth to migrate to more fine-grained compel
headers than follow the strategy 'one header to rule them all'.
Further, the header creates problems for cross-compilation: it's
included in files, those are used by host-compel. Which rightfully
confuses compiler/linker as host's definitions for fpu regs/other
platform details get drained into host's compel.
Signed-off-by: Dmitry Safonov <dima@arista.com>
The plan is to remove "compel.h". That file only includes other headers
(which may be not needed). If we aim for one-include-for-compel, we
could instead paste all subheaders into "compel.h".
Rather, I think it's worth to migrate to more fine-grained compel
headers than follow the strategy 'one header to rule them all'.
Further, the header creates problems for cross-compilation: it's
included in files, those are used by host-compel. Which rightfully
confuses compiler/linker as host's definitions for fpu regs/other
platform details get drained into host's compel.
As a first step - stop including "compel.h" in criu.
Signed-off-by: Dmitry Safonov <dima@arista.com>
To really open symlink file and not the regular file below it, one needs
to do open with O_PATH|O_NOFOLLOW flags. Looks like systemd started to
open /etc/localtime symlink this way sometimes, and before that nobody
actually used this and thus we never supported this in CRIU.
Error (criu/files-ext.c:96): Can't dump file 11 of that type [120777]
(unknown /etc/localtime)
Looks like it is quiet easy to support, as c/r of symlink file is almost
the same as c/r of regular one. We need to only make fstatat not
following links in check_path_remap.
Also we need to take into account support of ghost symlinks.
Signed-off-by: Alexander Mikhalitsyn (Virtuozzo) <alexander@mihalicyn.com>
Co-developed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
On these test without the patch ("fown: Don't fail on dumping files opened
wit O_PATH") we trigger these errors:
Error (criu/pie/parasite.c:340): fcntl(4, F_GETOWN_EX) -> -9
Error (criu/files.c:403): Can't get owner signum on 18: Bad file descriptor
Error (criu/files-reg.c:1887): Can't restore file pos: Bad file descriptor
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Alexander Mikhalitsyn (Virtuozzo) <alexander@mihalicyn.com>
O_PATH opened files are special: they have empty
file operations in kernel space, so there not that
much we can do with them, even setting position is
not allowed. Same applies to a signal number for
owner settings.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Co-developed-by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Signed-off-by: Alexander Mikhalitsyn (Virtuozzo) <alexander@mihalicyn.com>
python 2.7 doesn't call the read system call if it's read file to the
end once. The next seek allows to workaround this problem.
inhfd/memfd.py hangs due to this issue.
Reported-by: Mr Jenkins
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Right now, criu uses a dumped fd to dump content of a memfd "file".
Here are two reasons why we should not do this:
* a state of a dumped fd doesn't have to be changed, but now criu calls
lseek on it. This can be workarounded by using pread.
* a dumped descriptor can be write-only.
Reported-by: Mr Jenkins
Cc: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
Signed-off-by: Andrei Vagin <avagin@gmail.com>
The runc test cases are (sometimes) mounting a cgroup inside of the
container. For these tests to succeed, let CRIU know that cgroup2 exists
and how to restore such a mount.
This does not fix any specific cgroup2 settings, it just enables CRIU to
mount cgroup2 in the restored container.
Signed-off-by: Adrian Reber <areber@redhat.com>
More preparations for cgroupv2 freezer. Factor our the freezer state
opening and writing to have one location where to handle v1 and v2
differences.
Signed-off-by: Adrian Reber <areber@redhat.com>
The cgroupv2 freezer does not return the same strings as v1. Instead of
THAWED and FROZEN v2 returns 0 and 1 (strings). This prepares the seize
code to use 0 and 1 everywhere and THAWED and FROZEN only for v1
specific code paths.
Signed-off-by: Adrian Reber <areber@redhat.com>
This option was introduced with:
e2c38245c6
v2: (comment from Pavel Tikhomirov) --enable-fs does not fit with
--external dev[]:, see try_resolve_ext_mount, external dev mounts
only determined for FSTYPE__UNSUPPORTED.
Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com>
In the recent kernels the userfaultfd support for FORK events is limited to
CAP_SYS_PTRACE. That causes the followong error when the ioctl(UFFDIO_API)
is executed from non-privilieged userns:
Error (criu/uffd.c:273): uffd: Failed to get uffd API: Operation not permitted
Wrapping the call to ioctl(UFFDIO_API) in userns_call() resolves the issue.
Fixes: #964
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
gcc8 in Fedora Rawhide has a new useful warning:
> criu/img-remote.c: In function 'push_snapshot_id':
> criu/img-remote.c:1099:2: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation]
> 1099 | strncpy(rn.snapshot_id, snapshot_id, PATH_MAX);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From man 3 strncpy:
> Warning: If there is no null byte among the first n bytes of src,
> the string placed in dest will not be null-terminated.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Testing for all the memfd features, namely support for CR of:
* the same fd shared by multiple processes
* the same file shared by multiple processes
* the memfd content
* file flags and fd flags
* mmaps, MAP_SHARED and MAP_PRIVATE
* seals, excluding F_SEAL_FUTURE_WRITE because this feature only exists
in recent kernels (5.1 and up)
* inherited fd
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
File pairs naturally block on read() until the write() happen (or the
writer is closed). This is not the case for regular files, so we
take extra precaution for these.
Also cleaned-up an extra my_file.close()
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
See "man fcntl" for more information about seals.
memfd are the only files that can be sealed, currently. For this
reason, we dump the seal values in the MEMFD_INODE image.
Restoring seals must be done carefully as the seal F_SEAL_FUTURE_WRITE
prevents future write access. This means that any memory mapping with
write access must be restored before restoring the seals.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
* During checkpoint, we add a vma flags: VMA_AREA_MEMFD to denote memfd
regions.
* Even though memfd is backed by the shmem device, we use the file
semantics of memfd (via /proc/map_files/<vma>) which we already have
support for.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
Upon file restore, inherited_fd() is called to check for a user-defined
inerit-fd override. Note that the MEMFD_INODE image is read at each
invocation (memfd name is not cached).
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
See "man memfd_create" for more information of what memfd is.
This adds support for memfd open files, that are not not memory mapped.
* We add a new kind of file: MEMFD.
* We add two image types MEMFD_FILE, and MEMFD_INODE.
MEMFD_FILE contains usual file information (e.g., position).
MEMFD_INODE contains the memfd name, and a shmid identifier
referring to the content.
* We reuse the shmem facilities for dumping memfd content as it
would be easier to support incremental checkpoints in the future.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
