Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2009 Robert N. M. Watson
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This software was developed at the University of Cambridge Computer
|
|
|
|
* Laboratory with support from a grant from Google, Inc.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*-
|
|
|
|
* FreeBSD process descriptor facility.
|
|
|
|
*
|
|
|
|
* Some processes are represented by a file descriptor, which will be used in
|
|
|
|
* preference to signaling and pids for the purposes of process management,
|
|
|
|
* and is, in effect, a form of capability. When a process descriptor is
|
|
|
|
* used with a process, it ceases to be visible to certain traditional UNIX
|
|
|
|
* process facilities, such as waitpid(2).
|
|
|
|
*
|
|
|
|
* Some semantics:
|
|
|
|
*
|
|
|
|
* - At most one process descriptor will exist for any process, although
|
|
|
|
* references to that descriptor may be held from many processes (or even
|
|
|
|
* be in flight between processes over a local domain socket).
|
|
|
|
* - Last close on the process descriptor will terminate the process using
|
|
|
|
* SIGKILL and reparent it to init so that there's a process to reap it
|
|
|
|
* when it's done exiting.
|
|
|
|
* - If the process exits before the descriptor is closed, it will not
|
|
|
|
* generate SIGCHLD on termination, or be picked up by waitpid().
|
|
|
|
* - The pdkill(2) system call may be used to deliver a signal to the process
|
|
|
|
* using its process descriptor.
|
|
|
|
* - The pdwait4(2) system call may be used to block (or not) on a process
|
|
|
|
* descriptor to collect termination information.
|
|
|
|
*
|
|
|
|
* Open questions:
|
|
|
|
*
|
|
|
|
* - How to handle ptrace(2)?
|
|
|
|
* - Will we want to add a pidtoprocdesc(2) system call to allow process
|
2014-04-06 20:20:07 +00:00
|
|
|
* descriptors to be created for processes without pdfork(2)?
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
2014-03-16 10:55:57 +00:00
|
|
|
#include <sys/capsicum.h>
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
#include <sys/fcntl.h>
|
|
|
|
#include <sys/file.h>
|
|
|
|
#include <sys/filedesc.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/lock.h>
|
|
|
|
#include <sys/mutex.h>
|
|
|
|
#include <sys/poll.h>
|
|
|
|
#include <sys/proc.h>
|
|
|
|
#include <sys/procdesc.h>
|
|
|
|
#include <sys/resourcevar.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <sys/sysproto.h>
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
#include <sys/ucred.h>
|
|
|
|
|
|
|
|
#include <security/audit/audit.h>
|
|
|
|
|
|
|
|
#include <vm/uma.h>
|
|
|
|
|
|
|
|
FEATURE(process_descriptors, "Process Descriptors");
|
|
|
|
|
|
|
|
static uma_zone_t procdesc_zone;
|
|
|
|
|
|
|
|
static fo_poll_t procdesc_poll;
|
|
|
|
static fo_kqfilter_t procdesc_kqfilter;
|
|
|
|
static fo_stat_t procdesc_stat;
|
|
|
|
static fo_close_t procdesc_close;
|
|
|
|
|
|
|
|
static struct fileops procdesc_ops = {
|
2014-09-12 21:29:10 +00:00
|
|
|
.fo_read = invfo_rdwr,
|
|
|
|
.fo_write = invfo_rdwr,
|
|
|
|
.fo_truncate = invfo_truncate,
|
|
|
|
.fo_ioctl = invfo_ioctl,
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
.fo_poll = procdesc_poll,
|
|
|
|
.fo_kqfilter = procdesc_kqfilter,
|
|
|
|
.fo_stat = procdesc_stat,
|
|
|
|
.fo_close = procdesc_close,
|
2014-09-12 21:29:10 +00:00
|
|
|
.fo_chmod = invfo_chmod,
|
|
|
|
.fo_chown = invfo_chown,
|
2013-08-16 14:22:20 +00:00
|
|
|
.fo_sendfile = invfo_sendfile,
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
.fo_flags = DFLAG_PASSABLE,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize with VFS so that process descriptors are available along with
|
|
|
|
* other file descriptor types. As long as it runs before init(8) starts,
|
|
|
|
* there shouldn't be a problem.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
procdesc_init(void *dummy __unused)
|
|
|
|
{
|
|
|
|
|
|
|
|
procdesc_zone = uma_zcreate("procdesc", sizeof(struct procdesc),
|
|
|
|
NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
|
|
|
|
if (procdesc_zone == NULL)
|
|
|
|
panic("procdesc_init: procdesc_zone not initialized");
|
|
|
|
}
|
|
|
|
SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_ANY, procdesc_init, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return a locked process given a process descriptor, or ESRCH if it has
|
|
|
|
* died.
|
|
|
|
*/
|
|
|
|
int
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
procdesc_find(struct thread *td, int fd, cap_rights_t *rightsp,
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
struct proc **p)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
struct file *fp;
|
|
|
|
int error;
|
|
|
|
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
error = fget(td, fd, rightsp, &fp);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
if (fp->f_type != DTYPE_PROCDESC) {
|
|
|
|
error = EBADF;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
pd = fp->f_data;
|
|
|
|
sx_slock(&proctree_lock);
|
|
|
|
if (pd->pd_proc != NULL) {
|
|
|
|
*p = pd->pd_proc;
|
|
|
|
PROC_LOCK(*p);
|
|
|
|
} else
|
|
|
|
error = ESRCH;
|
|
|
|
sx_sunlock(&proctree_lock);
|
|
|
|
out:
|
|
|
|
fdrop(fp, td);
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function to be used by procstat(1) sysctls when returning procdesc
|
|
|
|
* information.
|
|
|
|
*/
|
|
|
|
pid_t
|
|
|
|
procdesc_pid(struct file *fp_procdesc)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
|
|
|
|
KASSERT(fp_procdesc->f_type == DTYPE_PROCDESC,
|
|
|
|
("procdesc_pid: !procdesc"));
|
|
|
|
|
|
|
|
pd = fp_procdesc->f_data;
|
|
|
|
return (pd->pd_pid);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve the PID associated with a process descriptor.
|
|
|
|
*/
|
|
|
|
int
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
kern_pdgetpid(struct thread *td, int fd, cap_rights_t *rightsp, pid_t *pidp)
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
{
|
|
|
|
struct file *fp;
|
|
|
|
int error;
|
|
|
|
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
error = fget(td, fd, rightsp, &fp);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
if (fp->f_type != DTYPE_PROCDESC) {
|
|
|
|
error = EBADF;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
*pidp = procdesc_pid(fp);
|
|
|
|
out:
|
|
|
|
fdrop(fp, td);
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* System call to return the pid of a process given its process descriptor.
|
|
|
|
*/
|
|
|
|
int
|
2011-09-16 13:58:51 +00:00
|
|
|
sys_pdgetpid(struct thread *td, struct pdgetpid_args *uap)
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
{
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
cap_rights_t rights;
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
pid_t pid;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
AUDIT_ARG_FD(uap->fd);
|
Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
2013-09-05 00:09:56 +00:00
|
|
|
error = kern_pdgetpid(td, uap->fd,
|
|
|
|
cap_rights_init(&rights, CAP_PDGETPID), &pid);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
if (error == 0)
|
|
|
|
error = copyout(&pid, uap->pidp, sizeof(pid));
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When a new process is forked by pdfork(), a file descriptor is allocated
|
|
|
|
* by the fork code first, then the process is forked, and then we get a
|
|
|
|
* chance to set up the process descriptor. Failure is not permitted at this
|
|
|
|
* point, so procdesc_new() must succeed.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
procdesc_new(struct proc *p, int flags)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
|
|
|
|
pd = uma_zalloc(procdesc_zone, M_WAITOK | M_ZERO);
|
|
|
|
pd->pd_proc = p;
|
|
|
|
pd->pd_pid = p->p_pid;
|
|
|
|
p->p_procdesc = pd;
|
|
|
|
pd->pd_flags = 0;
|
|
|
|
if (flags & PD_DAEMON)
|
|
|
|
pd->pd_flags |= PDF_DAEMON;
|
|
|
|
PROCDESC_LOCK_INIT(pd);
|
2014-04-07 18:10:49 +00:00
|
|
|
knlist_init_mtx(&pd->pd_selinfo.si_note, &pd->pd_lock);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Process descriptors start out with two references: one from their
|
|
|
|
* struct file, and the other from their struct proc.
|
|
|
|
*/
|
|
|
|
refcount_init(&pd->pd_refcount, 2);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize a file with a process descriptor.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
procdesc_finit(struct procdesc *pdp, struct file *fp)
|
|
|
|
{
|
|
|
|
|
|
|
|
finit(fp, FREAD | FWRITE, DTYPE_PROCDESC, pdp, &procdesc_ops);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
procdesc_free(struct procdesc *pd)
|
|
|
|
{
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When the last reference is released, we assert that the descriptor
|
|
|
|
* has been closed, but not that the process has exited, as we will
|
|
|
|
* detach the descriptor before the process dies if the descript is
|
|
|
|
* closed, as we can't wait synchronously.
|
|
|
|
*/
|
|
|
|
if (refcount_release(&pd->pd_refcount)) {
|
|
|
|
KASSERT(pd->pd_proc == NULL,
|
|
|
|
("procdesc_free: pd_proc != NULL"));
|
|
|
|
KASSERT((pd->pd_flags & PDF_CLOSED),
|
|
|
|
("procdesc_free: !PDF_CLOSED"));
|
|
|
|
|
2014-04-07 18:10:49 +00:00
|
|
|
knlist_destroy(&pd->pd_selinfo.si_note);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
PROCDESC_LOCK_DESTROY(pd);
|
|
|
|
uma_zfree(procdesc_zone, pd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* procdesc_exit() - notify a process descriptor that its process is exiting.
|
|
|
|
* We use the proctree_lock to ensure that process exit either happens
|
|
|
|
* strictly before or strictly after a concurrent call to procdesc_close().
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
procdesc_exit(struct proc *p)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
|
|
|
|
sx_assert(&proctree_lock, SA_XLOCKED);
|
|
|
|
PROC_LOCK_ASSERT(p, MA_OWNED);
|
|
|
|
KASSERT(p->p_procdesc != NULL, ("procdesc_exit: p_procdesc NULL"));
|
|
|
|
|
|
|
|
pd = p->p_procdesc;
|
|
|
|
|
|
|
|
PROCDESC_LOCK(pd);
|
|
|
|
KASSERT((pd->pd_flags & PDF_CLOSED) == 0 || p->p_pptr == initproc,
|
|
|
|
("procdesc_exit: closed && parent not init"));
|
|
|
|
|
|
|
|
pd->pd_flags |= PDF_EXITED;
|
2014-04-07 18:10:49 +00:00
|
|
|
pd->pd_xstat = p->p_xstat;
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the process descriptor has been closed, then we have nothing
|
|
|
|
* to do; return 1 so that init will get SIGCHLD and do the reaping.
|
|
|
|
* Clean up the procdesc now rather than letting it happen during
|
|
|
|
* that reap.
|
|
|
|
*/
|
|
|
|
if (pd->pd_flags & PDF_CLOSED) {
|
|
|
|
PROCDESC_UNLOCK(pd);
|
|
|
|
pd->pd_proc = NULL;
|
|
|
|
p->p_procdesc = NULL;
|
|
|
|
procdesc_free(pd);
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
if (pd->pd_flags & PDF_SELECTED) {
|
|
|
|
pd->pd_flags &= ~PDF_SELECTED;
|
|
|
|
selwakeup(&pd->pd_selinfo);
|
|
|
|
}
|
2014-04-07 18:10:49 +00:00
|
|
|
KNOTE_LOCKED(&pd->pd_selinfo.si_note, NOTE_EXIT);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
PROCDESC_UNLOCK(pd);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When a process descriptor is reaped, perhaps as a result of close() or
|
|
|
|
* pdwait4(), release the process's reference on the process descriptor.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
procdesc_reap(struct proc *p)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
|
|
|
|
sx_assert(&proctree_lock, SA_XLOCKED);
|
|
|
|
KASSERT(p->p_procdesc != NULL, ("procdesc_reap: p_procdesc == NULL"));
|
|
|
|
|
|
|
|
pd = p->p_procdesc;
|
|
|
|
pd->pd_proc = NULL;
|
2012-09-01 11:21:56 +00:00
|
|
|
p->p_procdesc = NULL;
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
procdesc_free(pd);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* procdesc_close() - last close on a process descriptor. If the process is
|
2012-06-19 22:23:59 +00:00
|
|
|
* still running, terminate with SIGKILL (unless PDF_DAEMON is set) and let
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
* init(8) clean up the mess; if not, we have to clean up the zombie ourselves.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
procdesc_close(struct file *fp, struct thread *td)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
struct proc *p;
|
|
|
|
|
|
|
|
KASSERT(fp->f_type == DTYPE_PROCDESC, ("procdesc_close: !procdesc"));
|
|
|
|
|
|
|
|
pd = fp->f_data;
|
|
|
|
fp->f_ops = &badfileops;
|
|
|
|
fp->f_data = NULL;
|
|
|
|
|
|
|
|
sx_xlock(&proctree_lock);
|
|
|
|
PROCDESC_LOCK(pd);
|
|
|
|
pd->pd_flags |= PDF_CLOSED;
|
|
|
|
PROCDESC_UNLOCK(pd);
|
|
|
|
p = pd->pd_proc;
|
2012-09-01 11:21:56 +00:00
|
|
|
if (p == NULL) {
|
|
|
|
/*
|
|
|
|
* This is the case where process' exit status was already
|
|
|
|
* collected and procdesc_reap() was already called.
|
|
|
|
*/
|
|
|
|
sx_xunlock(&proctree_lock);
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
} else {
|
2012-09-01 11:21:56 +00:00
|
|
|
PROC_LOCK(p);
|
2014-04-06 20:00:42 +00:00
|
|
|
if (p->p_state == PRS_ZOMBIE) {
|
|
|
|
/*
|
|
|
|
* If the process is already dead and just awaiting
|
|
|
|
* reaping, do that now. This will release the
|
|
|
|
* process's reference to the process descriptor when it
|
|
|
|
* calls back into procdesc_reap().
|
|
|
|
*/
|
|
|
|
PROC_SLOCK(p);
|
|
|
|
proc_reap(curthread, p, NULL, 0);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If the process is not yet dead, we need to kill it,
|
|
|
|
* but we can't wait around synchronously for it to go
|
|
|
|
* away, as that path leads to madness (and deadlocks).
|
|
|
|
* First, detach the process from its descriptor so that
|
|
|
|
* its exit status will be reported normally.
|
|
|
|
*/
|
|
|
|
pd->pd_proc = NULL;
|
|
|
|
p->p_procdesc = NULL;
|
|
|
|
procdesc_free(pd);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Next, reparent it to init(8) so that there's someone
|
|
|
|
* to pick up the pieces; finally, terminate with
|
|
|
|
* prejudice.
|
|
|
|
*/
|
|
|
|
p->p_sigparent = SIGCHLD;
|
|
|
|
proc_reparent(p, initproc);
|
|
|
|
if ((pd->pd_flags & PDF_DAEMON) == 0)
|
|
|
|
kern_psignal(p, SIGKILL);
|
|
|
|
PROC_UNLOCK(p);
|
|
|
|
sx_xunlock(&proctree_lock);
|
|
|
|
}
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Release the file descriptor's reference on the process descriptor.
|
|
|
|
*/
|
|
|
|
procdesc_free(pd);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
procdesc_poll(struct file *fp, int events, struct ucred *active_cred,
|
|
|
|
struct thread *td)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
int revents;
|
|
|
|
|
|
|
|
revents = 0;
|
|
|
|
pd = fp->f_data;
|
|
|
|
PROCDESC_LOCK(pd);
|
|
|
|
if (pd->pd_flags & PDF_EXITED)
|
|
|
|
revents |= POLLHUP;
|
|
|
|
if (revents == 0) {
|
|
|
|
selrecord(td, &pd->pd_selinfo);
|
|
|
|
pd->pd_flags |= PDF_SELECTED;
|
|
|
|
}
|
|
|
|
PROCDESC_UNLOCK(pd);
|
|
|
|
return (revents);
|
|
|
|
}
|
|
|
|
|
2014-04-07 18:10:49 +00:00
|
|
|
static void
|
|
|
|
procdesc_kqops_detach(struct knote *kn)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
|
|
|
|
pd = kn->kn_fp->f_data;
|
|
|
|
knlist_remove(&pd->pd_selinfo.si_note, kn, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
procdesc_kqops_event(struct knote *kn, long hint)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
u_int event;
|
|
|
|
|
|
|
|
pd = kn->kn_fp->f_data;
|
|
|
|
if (hint == 0) {
|
|
|
|
/*
|
|
|
|
* Initial test after registration. Generate a NOTE_EXIT in
|
|
|
|
* case the process already terminated before registration.
|
|
|
|
*/
|
|
|
|
event = pd->pd_flags & PDF_EXITED ? NOTE_EXIT : 0;
|
|
|
|
} else {
|
|
|
|
/* Mask off extra data. */
|
|
|
|
event = (u_int)hint & NOTE_PCTRLMASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the user is interested in this event, record it. */
|
|
|
|
if (kn->kn_sfflags & event)
|
|
|
|
kn->kn_fflags |= event;
|
|
|
|
|
|
|
|
/* Process is gone, so flag the event as finished. */
|
|
|
|
if (event == NOTE_EXIT) {
|
|
|
|
kn->kn_flags |= EV_EOF | EV_ONESHOT;
|
|
|
|
if (kn->kn_fflags & NOTE_EXIT)
|
|
|
|
kn->kn_data = pd->pd_xstat;
|
|
|
|
if (kn->kn_fflags == 0)
|
|
|
|
kn->kn_flags |= EV_DROP;
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (kn->kn_fflags != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct filterops procdesc_kqops = {
|
|
|
|
.f_isfd = 1,
|
|
|
|
.f_detach = procdesc_kqops_detach,
|
|
|
|
.f_event = procdesc_kqops_event,
|
|
|
|
};
|
|
|
|
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
static int
|
|
|
|
procdesc_kqfilter(struct file *fp, struct knote *kn)
|
|
|
|
{
|
2014-04-07 18:10:49 +00:00
|
|
|
struct procdesc *pd;
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
|
2014-04-07 18:10:49 +00:00
|
|
|
pd = fp->f_data;
|
|
|
|
switch (kn->kn_filter) {
|
|
|
|
case EVFILT_PROCDESC:
|
|
|
|
kn->kn_fop = &procdesc_kqops;
|
|
|
|
kn->kn_flags |= EV_CLEAR;
|
|
|
|
knlist_add(&pd->pd_selinfo.si_note, kn, 0);
|
|
|
|
return (0);
|
|
|
|
default:
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
Add experimental support for process descriptors
A "process descriptor" file descriptor is used to manage processes
without using the PID namespace. This is required for Capsicum's
Capability Mode, where the PID namespace is unavailable.
New system calls pdfork(2) and pdkill(2) offer the functional equivalents
of fork(2) and kill(2). pdgetpid(2) allows querying the PID of the remote
process for debugging purposes. The currently-unimplemented pdwait(2) will,
in the future, allow querying rusage/exit status. In the interim, poll(2)
may be used to check (and wait for) process termination.
When a process is referenced by a process descriptor, it does not issue
SIGCHLD to the parent, making it suitable for use in libraries---a common
scenario when using library compartmentalisation from within large
applications (such as web browsers). Some observers may note a similarity
to Mach task ports; process descriptors provide a subset of this behaviour,
but in a UNIX style.
This feature is enabled by "options PROCDESC", but as with several other
Capsicum kernel features, is not enabled by default in GENERIC 9.0.
Reviewed by: jhb, kib
Approved by: re (kib), mentor (rwatson)
Sponsored by: Google Inc
2011-08-18 22:51:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
procdesc_stat(struct file *fp, struct stat *sb, struct ucred *active_cred,
|
|
|
|
struct thread *td)
|
|
|
|
{
|
|
|
|
struct procdesc *pd;
|
|
|
|
struct timeval pstart;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXXRW: Perhaps we should cache some more information from the
|
|
|
|
* process so that we can return it reliably here even after it has
|
|
|
|
* died. For example, caching its credential data.
|
|
|
|
*/
|
|
|
|
bzero(sb, sizeof(*sb));
|
|
|
|
pd = fp->f_data;
|
|
|
|
sx_slock(&proctree_lock);
|
|
|
|
if (pd->pd_proc != NULL) {
|
|
|
|
PROC_LOCK(pd->pd_proc);
|
|
|
|
|
|
|
|
/* Set birth and [acm] times to process start time. */
|
|
|
|
pstart = pd->pd_proc->p_stats->p_start;
|
|
|
|
timevaladd(&pstart, &boottime);
|
|
|
|
TIMEVAL_TO_TIMESPEC(&pstart, &sb->st_birthtim);
|
|
|
|
sb->st_atim = sb->st_birthtim;
|
|
|
|
sb->st_ctim = sb->st_birthtim;
|
|
|
|
sb->st_mtim = sb->st_birthtim;
|
|
|
|
if (pd->pd_proc->p_state != PRS_ZOMBIE)
|
|
|
|
sb->st_mode = S_IFREG | S_IRWXU;
|
|
|
|
else
|
|
|
|
sb->st_mode = S_IFREG;
|
|
|
|
sb->st_uid = pd->pd_proc->p_ucred->cr_ruid;
|
|
|
|
sb->st_gid = pd->pd_proc->p_ucred->cr_rgid;
|
|
|
|
PROC_UNLOCK(pd->pd_proc);
|
|
|
|
} else
|
|
|
|
sb->st_mode = S_IFREG;
|
|
|
|
sx_sunlock(&proctree_lock);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|