Gidday,
The Linux man-pages maintainer proudly announces:
man-pages-3.80 - man pages for Linux
Tarball download:
http://www.kernel.org/doc/man-pages/download.html
Git repository:
https://git.kernel.org/cgit/docs/man-pages/man-pages.git/
Online changelog:
http://man7.org/linux/man-pages/changelog.html#release_3.80
A short summary of the release is blogged at:
http://linux-man-pages.blogspot.com/2015/02/man-pages-380-is-released.html
A selection of changes in this release that may be interesting
for readers of this list is shown below.
Cheers,
Michael
==================== Changes in man-pages-3.80 ====================
New and rewritten pages
-----------------------
ioctl_fat.2
Heinrich Schuchardt [Michael Kerrisk]
New man page for the ioctl(2) FAT API
The ioctl(2) system call may be used to retrieve information about
the FAT file system and to set file attributes.
madvise.2
Michael Kerrisk
Summary: this page has been significantly reorganised and rewritten
Newly documented interfaces in existing pages
---------------------------------------------
proc.5
Michael Kerrisk
(Briefly) document /proc/PID/attr/socketcreate
Michael Kerrisk
(Briefly) document /proc/PID/attr/keycreate
Michael Kerrisk [Stephen Smalley]
Document /proc/PID/attr/{current,exec,fscreate,prev}
Michael Kerrisk
Document /proc/sys/kernel/auto_msgmni
socket.7
David Wilson [Michael Kerrisk]
Document SO_REUSEPORT socket option
Changes to individual pages
---------------------------
access.2
Denys Vlasenko
Explain how access() check treats capabilities
We have users who are terribly confused why their binaries
with CAP_DAC_OVERRIDE capability see EACCESS from access() calls,
but are able to read the file.
The reason is access() isn't the "can I read/write/execute this
file?" question, it is the "(assuming that I'm a setuid binary,)
can *the user who invoked me* read/write/execute this file?"
question.
That's why it uses real UIDs as documented, and why it ignores
capabilities when capability-endorsed binaries are run by non-root
(this patch adds this information).
To make users more likely to notice this less-known detail,
the patch expands the explanation with rationale for this logic
into a separate paragraph.
arch_prctl.2
set_thread_area.2
get_thread_area.2
Andy Lutomirski
Improve TLS documentation
The documentation for set_thread_area was very vague. This
improves it, accounts for recent kernel changes, and merges
it with get_thread_area.2.
While I'm at it, clarify the related arch_prctl.2 man page.
capget.2
Michael Kerrisk
Document V3 capabilities constants
clone.2
Peng Haitao
Fix description of CLONE_PARENT_SETTID
CLONE_PARENT_SETTID only stores child thread ID in parent memory.
listxattr.2
Heinrich Schuchardt
Provide example program
modify_ldt.2
Andy Lutomirski
Overhaul the documentation
This clarifies the behavior and documents all four functions.
Andy Lutomirski
Clarify the lm bit's behavior
The lm bit should never have existed in the first place. Sigh.
mprotect.2
Mark Seaborn
Mention effect of READ_IMPLIES_EXEC personality flag
I puzzled over mprotect()'s effect on /proc/*/maps for a while
yesterday -- it was setting "x" without PROT_EXEC being specified.
Here is a patch to add some explanation.
msgget.2
Michael Kerrisk
Add details of MSGMNI default value
prctl.2
Michael Kerrisk
Greatly expand discussion of "dumpable" flag
In particular, detail the interactions with
/proc/sys/fs/suid_dumpable.
Michael Kerrisk
Executing a file with capabilities also resets the parent death signal
ptrace.2
James Hunt
Explain behaviour should ptrace tracer call execve(2)
Denys Vlasenko
Add information on PTRACE_SEIZE versus PTRACE_ATTACH differences
semget.2
Michael Kerrisk
Note default value for SEMMNI and SEMMSL
semop.2
Michael Kerrisk
Note defaults for SEMOPM and warn against increasing > 1000
statfs.2
Michael Kerrisk [Jan Chaloupka]
Document the 'f_flags' field added in Linux 2.6.36
statvfs.3
Michael Kerrisk
Document missing 'f_flag' bit values
Michael Kerrisk [Jan Chaloupka]
statvfs() now populates 'f_flag' from statfs()'s f_flag field
random.4
Michael Kerrisk
Note maximum number of bytes returned by read(2) on /dev/random
Michael Kerrisk [Mathieu Malaterre]
Since Linux 3.16, reads from /dev/urandom return at most 32 MB
See https://bugs.debian.org/775328 and
https://bugzilla.kernel.org/show_bug.cgi?id=80981#c9
core.5
Michael Kerrisk
Document "%i" and "%I" core_pattern specifiers
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/