Explain the effect that default ACLs have (instead of the umask)
in umask.2. Mention that default ACLs can have an affect in
open.2, mknod.2, and mkdir.2.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
According to POSIX, the the 9 UGO*RWX bits are permissions, and
'mode' is used to refer to collectively to those bits plus sticky,
set-UID, and set_GID bits.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Based on Ted T'so's commit message 0ae45f63d4e
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Cowritten-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
timerfd_create.2 mentions TFD_IOC_SET_TICKS. We should add it to
ioctl_list.2, too.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Really just a marker to record the reporters of bugs
that stemmed from the fact that the page did not
document getdents64(). I'll fix things up in the changelog.
See https://bugzilla.kernel.org/show_bug.cgi?id=14795
Reported-by: Dima Tisnek <dimaqq@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Three versions of "stat" appeared on 32-bit systems,
dealing with structures of different (increasing) sizes.
Explain some of the details, and also note that the
situation is simpler on modern 64-bit architectures.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The multiple-system-call-version phenomenon is particular a
feature of older 32-bit platforms. Hint at that fact in the text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the discussion of the new *64() system calls added in
Linux 2.4, use truncate64() father than ftruncate64(),
since the text goes on to say "and their analogs that work with
file descriptors or symbolic links".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
madvise(2) actually returns with error EINVAL for MADV_REMOVE
when used for hugetlb VMAs, not EOPNOTSUPP, and this has been
the case since MADV_REMOVE was introduced in commit f6b3ec238d12
("madvise(MADV_REMOVE): remove pages from tmpfs shm backing
store").
Specify the exact behavior.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The glibc wrapper gives an EINVAL error on attempts to change the
disposition of either of the two real-time signals used by NPTL.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the kernel level, credentials (UIDs and GIDs) are a per-thread
attribute. NPTL uses a signal-based mechanism to ensure that
when one thread changes its credentials, all other threads change
credentials to the same values. By this means, the NPTL
implementation conforms to the POSIX requirement that the threads
in a process share credentials.
Reported-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
> Jann Horn writes:
> > Or should I throw this patch away and write a patch
> > for the prctl() manpage instead that documents that
> > being able to call sigreturn() implies being able to
> > effectively call sigprocmask(), at least on some
> > architectures like X86?
>
> Well, that is the semantics of sigreturn(). It is essentially
> setcontext() [which includes the actions of sigprocmask()], but
> with restrictions on parameter placement (at least on x86).
>
> You could introduce some setting to restrict that aspect for
> seccomp processes, but you can't change this for normal processes
> without breaking things.
Then I think it's probably better and easier to just document the
existing behavior? If a new setting would have to be introduced
and developers would need to be aware of that, it's probably
easier to just tell everyone to use SIGKILL.
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Mikael Pettersson <mikpelinux@gmail.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 527: warning [p 6, 2.3i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 192: warning [p 2, 4.7i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The description mentions close(2). Hence it should also be referenced
in the SEE ALSO section.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The list of errnos for msgrcv() lists both EAGAIN and ENOMSG as
the errno for no message available with the IPC_NOWAIT flag.
ENOMSG is the errno that will be set.
Signed-off-by: Bill Pemberton <wfp5p@worldbroken.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I recently realized that I had been reasoning improperly about
what umount(MNT_DETACH) did based on an insufficient description
in the umount.2 man page, that matched my intuition but not the
implementation.
When there are no submounts, MNT_DETACH is essentially harmless to
applications. Where there are submounts, MNT_DETACH changes what
is visible to applications using the detach directories.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Include linux/ext2_fs.h does not contain any ioctl definitions
anymore.
Request codes EXT2_IOC* have been replaced by FS_IOC* in
linux/fs.h.
Some definitions of FS_IOC_* use long* but the actual code expects
int* (see fs/ext2/ioctl.c).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clone has so many effects that it's an oversimplification to say
that the *main* use of clone is to create a thread. (In fact,
the use of clone() to create new processes may well be more
common, since glibc's fork() is a wrapper that calls clone().)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Normally, system calls return EINVAL for flags they don't support.
Explicitly document that clone does *not* produce an error for these two
obsolete flags.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From email conversation with Konstantin:
> * Are you saying there are case where successful
> setsockopt() via nf_register_sockopt() might return a
> value other zero?
Yes - it happens when the option is served by a custom
netfilter hook (this is how I bumped into this). Example:
Userspace code:
=================== cut here ================================
int main(void) {
int sock;
if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
return -1;
return setsockopt(sock, IPPROTO_IP, TEST_SETSOCKOPT_RETURN, NULL, 0);
}
=================== cut here ================================
Kernel module, handling the option 400 "TEST_SETSOCKOPT_RETURN":
=================== cut here ================================
/* Random value - just should not be already used by the running
system: */
static int test_sock_set_so(struct sock *sk, int cmd, void *param,
unsigned len) {
return 42;
}
static struct nf_sockopt_ops test_sock_ops = {
list: {NULL, NULL},
pf: PF_INET,
set_optmin: TEST_SETSOCKOPT_RETURN,
set_optmax: (TEST_SETSOCKOPT_RETURN + 1),
set: test_sock_set_so,
get_optmin: 0,
get_optmax: 0,
get: NULL
};
static int test_sock_init(void) {
return nf_register_sockopt(&test_sock_ops); /* sanity check
skipped */
}
static void test_sock_exit(void) {
nf_unregister_sockopt(&test_sock_ops);
}
module_init(test_sock_init);
module_exit(test_sock_exit);
=================== cut here ================================
After successful loading of the module, the executable returns 42,
and as I understand, that is the intention of netfilter authors.
Netfilter code calls the registered handle and just returns back to
user what it receives from it.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
add FAT_IOCTL_GET_VOLUME_ID
SEE ALSO ioctl_fat.2
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Change "behaviour" to American spelling "behavior".
Signed-off-by: Bill Pemberton <wfp5p@worldbroken.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function mmap() and munmap() are thread safe.
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The number of padding bytes has changed over tyme, as some
bytes are used, so describe this aspect of the structure
less explicitly.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The point made in this fairly ancient text is more or less evident
from the DESCRIPTION, and it's not clear what "standard" is being
referred to.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As from upstream commit:
commit 3f31d07571eeea18a7d34db9af21d2285b807a17
Author: Hugh Dickins <hughd@google.com>
Date: Tue May 29 15:06:40 2012 -0700
mm/fs: route MADV_REMOVE to FALLOC_FL_PUNCH_HOLE
Now tmpfs supports hole-punching via fallocate(), switch madvise_remove()
to use do_fallocate() instead of vmtruncate_range(): which extends
madvise(,,MADV_REMOVE) support from tmpfs to ext4, ocfs2 and xfs.
madvise(,,MADV_REMOVE) support was extended by ext4, ocfs2 and xfs.
bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1120294
Justification from Rafael Aquini:
Well, that code is committed in kernel since v3.5 (2012) and it
surely is the expected behaviour since. It seems to me that
madvise(2) man page text for MADV_REMOVE just got out-of-date in
that regard.
This patch mentions this support in madvise.2 man page.
Reworded and corrected by Michael Kerrisk and Hugh Dickins. Thank you.
Signed-off-by: Jan Chaloupka <jchaloup@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Andreas Gruenbacher