The information here relates to ancient systems
Some (possibly more up to date) info can be found
in Documentation/kernel-parameters.txt.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
In the specific case of floppy drives: the drivers still
exist, but it's been a while since most of saw these devices
in the wild. So, just refer the reader to the kernel source
file for details. (The detail in this man page was after all
originally drawn from that file.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See kernel commit a88dc06cd515b3bb9dfa18606e88d0be9a5b6ddd
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
"xattr" is a more meaningful name than "attr" (it resonates
with the names of the system calls), so as long as we are
moving the page to a new section, we'll change the name as well,
and retain an acl(5) link so that old references remain valid.
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From experimentation, I found a 16kB limit on name + value +
overhead bytes. Digger deeper, I see that
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Unlimited_extended_attributes
says:
Unlimited extended attributes
Not claimed — no patches yet — Not in kernel yet
Currently size of value of an extended attribute must fit into
inline space (~3900 on 4k leaf size), while other filesystems
do not limit the size. Add a new b-tree item to hold the xattr
value in extents.
And reading mkfs.btrfs(8) reveals that the default node (AKA leaf)
size is 16kB.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After discussions with Andreas Gruenbacher, it makes sense to
move this page into man-pages, since it mostly relates to
kernel details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This was fixed in glibc 2.1.1, which is a long while ago.
And in any case, there is nothing special about this case;
it's just one of those times when glibc lags.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text makes no sense. The check is based
purely on a capability check. (Kernel function
net/packet/af_packet.c::packet_create()
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's important that the reader receive contemporary information.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
While a lot of the changes are issues of presentation,
there are also issues of grammar and punctuation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking over the man page for 'tcp' I came across a reference to
tuning the 'TCP_SYNQ_HSIZE' parameter when increasing
'tcp_max_syn_backlog' above 1024. However, this static sizing was
removed back in Linux 2.6.20 in favor of dynamic scaling - as
part of commit 72a3effaf633bcae9034b7e176bdbd78d64a71db.
I have included a patch below with reference to this commit, and
that the process detailed is not required on >= Linux 2.6.20.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
No (intentional) changes to factual description, but the
restructured text is hopefully easier to grasp.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
No (intentional) change to the facts, but this restructuring
should make the meaning easier to grasp.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It makes sense to have the description of this file
in the general discussion of user namespaces.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Files with access permissions such as rwx---rwx give fewer
permissions to their group then they do to everyone else. Which
means dropping groups with setgroups(0, NULL) actually grants a
process privileges.
The unprivileged setting of gid_map turned out not to be safe
after this change. Privileged setting of gid_map can be
interpreted as meaning yes it is ok to drop groups. [ Eric
additionally noted: Setting of gid_map with privilege has been
clarified to mean that dropping groups is ok. This allows
existing programs that set gid_map with privilege to work
without changes. That is, newgidmap(1) continues to work
unchanged.]
To prevent this problem and future problems, user namespaces were
changed in such a way as to guarantee a user can not obtain
credentials without privilege that they could not obtain without
the help of user namespaces.
This meant testing the effective user ID and not the filesystem
user ID, as setresuid(2) and setregid(2) allow setting any process
UID or GID (except the supplementary groups) to the effective ID.
Furthermore, to preserve in some form the useful applications
that have been setting gid_map without privilege, the file
/proc/[pid]/setgroups was added to allow disabling setgroups(2).
With setgroups(2) permanently disabled in a user namespace, it
again becomes safe to allow writes to gid_map without privilege.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As at Linux 3.18, the limit is still five lines, so mention the
more recent kernel version in the text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since the initial implementation a lot more checks were added.
Describe all the checks would be too verbose (and would soon
fall out of date as more checks are added). So instead, describe
the kinds of checks that are done more generally.
Also a few other minor edits to the text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk