Taken from Documentation/filesystems/proc.txt.
Reported-by: Helge Kreutzmann <debian@helgefjell.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The restriction to CAP_SYS_ADMIN was removed from map_files in
2015 [1]. There was a fixme that indicted this might happen, but
the main text was never updated when this commit landed. While
we're at it, add a note about the ptrace access check that is
still required.
[1] bdb4d100af
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The cmdline file is a window into memory that is controlled by the
target process, and that memory may be changed arbitrarily, as can
the window via prctl settings. Make sure people understand that
this file is all an illusion.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In many cases, these don't improve readability, and (when stacked)
they sometimes have the side effect of sometimes forcing text
to be justified within a narrow column range.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adjust references to namespaces(7) to be references to pages
describing specific namespace types.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Branden:
*roff escape sequences may sometimes look like C escapes, but that
is misleading. *roff is in part a macro language and that means
recursive expansion to arbitrary depths.
You can get away with "\\" in a context where no macro expansion
is taking place, but try to spell a literal backslash this way in
the argument to a macro and you will likely be unhappy with
results.
Try viewing the attached file with "man -l".
"\e" is the preferred and portable way to get a portable "escape
literal" going back to CSTR #54, the original Bell Labs troff
paper.
groff(7) discusses the issue:
\\ reduces to a single backslash; useful to delay its
interpretation as escape character in copy mode. For a
printable backslash, use \e, or even better \[rs], to be
independent from the current escape character.
As of groff 1.22.4, groff_man(7) does as well:
\e Widely used in man pages to represent a backslash output
glyph. It works reliably as long as the .ec request is
not used, which should never happen in man pages, and it
is slightly more portable than the more exact ‘\(rs’
(“reverse solidus”) escape sequence.
People not concerned with portability to extremely old troffs should
probably just use \(rs (or \[rs]), as it means "the backslash
glyph", not "the glyph corresponding to whatever the current escape
character is".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fs/proc/uptime.c:uptime_proc_show() fetches time using
ktime_get_boottime which includes the time spent in suspend.
Signed-off-by: Stephan Knauss <linux@stephans-server.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See Linux commit a5ad88ce8c7fae7ddc72ee49a11a75aa837788e0,
"mm: get rid of 'vmalloc_info' from /proc/meminfo".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The extra detail has little of noting with -test 2.6.0
added a particular feature has little value these days,
and is likely to confuse some readers who don't know
(and probably don't care) about the historical details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This is in effect a revert of
commit 1391278030
Reported-by: Alexander E. Patrakov <patrakov@gmail.com>
Reported-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Extended information for timerfd file descriptors in
/proc/[pid]/fdinfo was added in commit af9c4957cf21 ("timerfd:
Implement show_fdinfo method", 2014-07-16), to support
checkpoint/restore for such file descriptors (see also the
TFD_IOC_SET_TICKS ioctl which is documented in timerfd_create.2).
Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Pathname escaping is not done properly in /proc/<pid>/maps;
because of this, different pathnames may appear the same
(verified by experiment and reading the source code).
Further details from Elvira about the relevant location in
the kernel code:
show_map_vma() from fs/proc/task_mmu.c uses seq_file_path()
from fs/seq_file.c to print the dentry name, which in turn
calls seq_path() from the same file. seq_path() uses
d_path() from fs/d_path.c to get the path name; this is
where the " (deleted)" part comes from. This is followed by
mangling the string with mangle_path() (fs/seq_file.c); this
function only replaces those characters that were supplied
in the "esc" argument and does not bother with escaping
anything else ('\\', for example). The value of this
argument comes without modifications from the initial call
of seq_file_path() by show_map_vma(), and that is "\n".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The left-most pid namespace in a given procfs' `NStgid` does not
change based on the pid namespace of the reading process. Rather,
each procfs has an associated outer-most namespace, which gets
set when the procfs is mounted:
```
static struct dentry *proc_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
struct pid_namespace *ns;
if (flags & MS_KERNMOUNT) {
ns = data;
data = NULL;
} else {
ns = task_active_pid_ns(current);
}
return mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
}
```
i.e. either the root namespace for kernel mounts or the namespace
of the mounting process. This ns then gets saved in the fs' super
block and is the basis for most operations. It is this ns that the
left-most value of `NStgid` is relative to, not the reading process.
Reported-by: Robert O'Callahan <robert@ocallahan.org>
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Explain how to determine the top-most mount at a particular
location by inspecting /proc/PID/mountinfo.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Starting in Linux 4.11, if the process dumpable attribute is
not 1 and the process resides in a noninitial namespaces that
has valid mappings for UID 0 and GID 0, then the ownership of
/proc/PID/* is made the same as the root IDs of the namespace.
Determined by inspection of fs/proc/base.c
See also the following kernel commit:
commit 68eb94f16227336a5773b83ecfa8290f1d6b78ce
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Tue Jan 3 10:23:11 2017 +1300
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The statement that resetting the dumpable attribute of a process
to 1 causes the ownership of files to revert the process's real
IDs looked suspect. And indeed it is at odds with the code in
fs/proc/base.c::task_dump_owner() (Linux 4.16 sources).
Further verified with a quick test that resetting dumpable to 1
causes the ownership of /proc/PID/* files to revert to the
process's effective IDs. Mea culpa for the original mistake.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After comments from Miklos, and further digging in the kernel
source that showed that chroot() can also result in "hidden"
parent-IDs in mountinfo, I've revised the description of
mountinfo.
In fs/proc_namespace.cs::how_mountinfo() there is:
/* mountpoints outside of chroot jail will give SEQ_SKIP on this */
err = seq_path_root(m, &mnt_path, &p->root, " \t\n\\");
if (err)
goto out;
I instrumented the 'if (err)' code path with printk()
to show that there is indeed a record corresponding to the
parent-ID for the process root that is being skipped.
Reported-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I do not have an exact handle on the details, but I can see
roughly what is going on. Internally, there seems to be one
("hidden") mount ID reserved to each mount namespace, and that ID
is the parent of the root mount point.
Looking through the (4.14) kernel source, mount IDs are allocated
by a kernel function called mnt_alloc_id() (in fs/namespace.c),
which is in turn called by alloc_vfsmnt() which is in turn called
by clone_mnt().
A new mount namespace is created by the kernel function
copy_mnt_ns() (in fs/namespace.c, called by
create_new_namespaces() in kernel/nsproxy.c). The copy_mnt_ns()
function calls copy_tree() (in fs/namespace.c), and copy_tree()
calls clone_mnt() in *two* places. The first of these is the call
that creates the "hidden" mount ID that becomes the parent of the
root mount point. (I verified this by instrumenting the kernel
with a few printk() calls to display the IDs.) The second place
where copy_tree() calls clone_mnt() is in a loop that replicates
each of the mount points (including the root mount point) in the
source mount namespace.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After Linux 2.6.36, the heuristic calculation of oom_score
has changed to only consider used memory and CAP_SYS_ADMIN.
See kernel commit a63d83f427fbce97a6cea0db2e64b0eb8435cd10.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the seccomp /proc interfaces in Linux 4.14:
/proc/sys/kernel/seccomp/actions_avail and
/proc/sys/kernel/seccomp/actions_logged.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since the symbolic links for pipes and sockets do not refer to real
files in the file system tree, it can be hard to discover that they
still have mode and ownership information (revealed e.g. by `stat -L`),
so let's point this out in the manpage.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When referring to the architecture, consistently use "x86-64",
not "x86_64". Hitherto, there was a mixture of usages, with
"x86-64" predominant.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk