The POSIX timers API is implemented (mostly) within the kernel,
so thse interfaces are system calls. Although there are as yet
no man pages, when they are added they should be in Section 2,
not 3. Therefore fix those pages that currently refer to these
interfaces as being in Section 3.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX.1-2001 says that the values returned by sysconf()
are constant for the life of the process.
But the fact that, since Linux 2.6.23, ARG_MAX is settable
via RLIMIT_STACK means _SC_ARG_MAX is no longer constant,
since it can change at each execve().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Starting with Linux 2.6.23, the ARG_MAX limit became settable via
(1/4 of) RLIMIT_STACK. This broke ABI compatibility if RLIMIT_STACK
was set such that ARG_MAX was < 32 pages. Document the fact that
since 2.6.25 Linux imposes a floor on ARG_MAX, so that the old limit
of 32 pages is guaranteed.
For some background on the changes to ARG_MAX in kernels 2.6.23 and
2.6.25, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=5786http://bugzilla.kernel.org/show_bug.cgi?id=10095http://thread.gmane.org/gmane.linux.kernel/646709/focus=648101,
checked into 2.6.25 as commit a64e715fc74b1a7dcc5944f848acc38b2c4d4ee2.
Also some reordering/rewording of the discussion of ARG_MAX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Using a NULL envp does in fact seem to be portable (works
on Solaris and FreeBSD), but the Linux semantics for a NULL
argv certainly aren't consistent with other implementations.
See http://bugzilla.kernel.org/show_bug.cgi?id=8408.
Expanded the discussion of interpreter scripts and the
'optional-arg' argument of an interpreter script.
Added text noting that FD_CLOEXEC causes record locks to be released.
NULL, but warning that this is non-standard and non-portable,
and should be avoided in portable programs.
Bug filed (http://bugzilla.kernel.org/show_bug.cgi?id=8408)
to get this changed, but maybe that won't be done because it
is an ABI change.
> The question came up whether execve of a suid binary while being ptraced
> would fail or ignore the suid part. The answer today seems to be the
> latter:
>
> E.g. (in 2.6.11) security/dummy.c:
>
> static void dummy_bprm_apply_creds (struct linux_binprm *bprm, int
> unsafe)
> {
> if (bprm->e_uid != current->uid || bprm->e_gid != current->gid) {
> if ((unsafe & ~LSM_UNSAFE_PTRACE_CAP) &&
> !capable(CAP_SETUID)) {
> bprm->e_uid = current->uid;
> bprm->e_gid = current->gid;
> }
> }
> }
>
> and fs/exec.c:
>
> void compute_creds(struct linux_binprm *bprm) {
> int unsafe;
>
> unsafe = unsafe_exec(current);
> security_bprm_apply_creds(bprm, unsafe);
> }
>
> static inline int unsafe_exec(struct task_struct *p) {
> int unsafe = 0;
> if (p->ptrace & PT_PTRACED) {
> if (p->ptrace & PT_PTRACE_CAP)
> unsafe |= LSM_UNSAFE_PTRACE_CAP;
> else
> unsafe |= LSM_UNSAFE_PTRACE;
> }
> return unsafe;
> }
>
> That is: if the process that calls execve() is being traced,
> the LSM_UNSAFE_PTRACE bit is et in unsafe and security_bprm_apply_creds()
> will make sure the suid/sgid bits are ignored.
>
> ---
>
> In my man page I do not read anything like that. It says
>
> EPERM The process is being traced, the user is not the superuser and
> the file has an SUID or SGID bit set.
> and
>
> If the current program is being ptraced, a SIGTRAP is sent to it after
> a successful execve().
>
> If the set-uid bit is set on the program file pointed to by filename
> the effective user ID of the calling process is changed to that of the
> owner of the program file.
>
> So, maybe this sentence should be amended to read
>
> If the set-uid bit is set on the program file pointed to by filename
> and the current process is not being ptraced, the effective user ID
> of the calling process is changed to ...
I changed your "current" to "calling" (to be consistent with the
rest of the page), but otherwise applied as you suggest.
The revision will appear in man-pages-2.03, which I can release
any time now. Are you avialable to do an upload tomorrow?