The Linux 3.10 release dropped the c/r requirement and opened it
up to all users.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel will immediately reject calls where arg4/arg5 are not
zero. See kernel/sys.c:prctl_set_mm().
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Formerly, if the limit of 32 nested user namespaces was exceeded,
the error EUSERS resulted. Starting with Linux 4.9, the error
is ENOSPC.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently it says when dirfd is AT_FDCWD it can be something
other than directory, which doesn't make much sense. Just swap
the order of sentences.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The BLKRASET/BLKRAGET ioctls() take unsigned long, if I pass int * to
the BLKRAGET ioctl on x86_64 (or on any other arch where sizeof(int) !=
sizeof(long)) the BLKRAGET ioctl will rewrite four bytes on the stack.
If you look at block/ioctl.c in kernel sources you can clearly see that
BLKRAGET ioctl calls put_long().
Compile following reproducer and run it as ./a.out /dev/sda, you can see
that the second member of the array will be zeroed. If you change the
array to have only one member you will see stack smashing trace.
I also wonder if it's OK to pass int value to ioctl() at all, the arg
value seems to be unsigned long in the syscall definition in fs/ioctl.c
and there does not seem to be any glibc magic around the syscall.
-------------------------8<----------------------------
static int fd;
int main(int argc, char *argv[])
{
int ra[] = {100, 100};
fd = open(argv[1], O_RDONLY);
if (fd < 0) {
perror("open");
return 1;
}
ioctl(fd, BLKRAGET, ra);
fprintf(stderr, "%i %i\n", ra[0], ra[1]);
return 0;
}
-------------------------8<----------------------------
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
tempnam() takes the TMPDIR environment variable into account, unlike
tmpnam(), which always creates pathnames within /tmp.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As far as I can see, file seals can be applied only to
memfd_create(2) file descriptors. This was checked by experiment
and by reading mm/shmem.c::shmem_get_inode((), where one finds
the following line that applies to all new shmem files:
info->seals = F_SEAL_SEAL;
Only in the code of the memfd_create() system call is this
setting reversed (in mm/shmem.c::memfd_create):
if (flags & MFD_ALLOW_SEALING)
info->seals &= ~F_SEAL_SEAL;
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
MAP_AUTOGROW, MAP_AUTORESRV, MAP_COPY, and MAP_LOCAL may have
appeared on some systems many years ago, but the discussion here
mentions no details and the systems and flags probably ceased to
be relevant long ago. So, remove this text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
'events' specified as zero still allows EPOLLHUP and
EPOLLERR to be reported.
Reported-by: Nicolas Biscos <nicolas.biscos+man7@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk