summaryrefslogtreecommitdiffstats
path: root/abs/core/libcap/libcap-1.10-debian.patch
diff options
context:
space:
mode:
authorMichael Hanson <hansonorders@verizon.net>2010-11-30 23:52:49 (GMT)
committerMichael Hanson <hansonorders@verizon.net>2010-11-30 23:52:49 (GMT)
commitef974fb08972483d6852c9d5b2f23e1d33343b76 (patch)
treefa5aad1563681bf14a0fed3cdf8f599f7e8e853c /abs/core/libcap/libcap-1.10-debian.patch
parentba6da4b6e7eab74dd3dcac947a11361b1b9f1eed (diff)
downloadlinhes_pkgbuild-ef974fb08972483d6852c9d5b2f23e1d33343b76.zip
linhes_pkgbuild-ef974fb08972483d6852c9d5b2f23e1d33343b76.tar.gz
linhes_pkgbuild-ef974fb08972483d6852c9d5b2f23e1d33343b76.tar.bz2
Housekeeping
Diffstat (limited to 'abs/core/libcap/libcap-1.10-debian.patch')
-rw-r--r--abs/core/libcap/libcap-1.10-debian.patch766
1 files changed, 0 insertions, 766 deletions
diff --git a/abs/core/libcap/libcap-1.10-debian.patch b/abs/core/libcap/libcap-1.10-debian.patch
deleted file mode 100644
index 26d57ec..0000000
--- a/abs/core/libcap/libcap-1.10-debian.patch
+++ /dev/null
@@ -1,766 +0,0 @@
---- libcap-1.10.orig/doc/old/cap_set_fd.3
-+++ libcap-1.10/doc/old/cap_set_fd.3
-@@ -0,0 +1 @@
-+.so man3/cap_get_file.3
---- libcap-1.10.orig/doc/old/cap_set_file.3
-+++ libcap-1.10/doc/old/cap_set_file.3
-@@ -0,0 +1 @@
-+.so man3/cap_get_file.3
---- libcap-1.10.orig/doc/capset.2
-+++ libcap-1.10/doc/capset.2
-@@ -1 +1 @@
--.so man2/capget.2
-+#.so man2/capget.2
---- libcap-1.10.orig/doc/Makefile
-+++ libcap-1.10/doc/Makefile
-@@ -7,7 +7,7 @@
- topdir=$(shell pwd)/..
- include $(topdir)/Make.Rules
-
--MAN2S = capget.2 capset.2
-+#MAN2S = capget.2
- MAN3S = cap_init.3 cap_free.3 cap_dup.3 \
- cap_clear.3 cap_get_flag.3 cap_set_flag.3 \
- cap_get_proc.3 cap_set_proc.3 \
---- libcap-1.10.orig/Make.Rules
-+++ libcap-1.10/Make.Rules
-@@ -8,7 +8,7 @@
-
- # common 'packaging' directoty
-
--FAKEROOT=
-+FAKEROOT=$(DESTDIR)
-
- # Autoconf-style prefixes are activated when $(prefix) is defined.
- # Otherwise binaries and libraraies are installed in /{lib,sbin}/,
-@@ -18,13 +18,13 @@
- exec_prefix=$(prefix)
- lib_prefix=$(exec_prefix)
- inc_prefix=$(lib_prefix)
--man_prefix=$(prefix)
-+man_prefix=$(prefix)/share
- else
- prefix=/usr
- exec_prefix=
- lib_prefix=$(exec_prefix)
- inc_prefix=$(prefix)
--man_prefix=$(prefix)
-+man_prefix=$(prefix)/share
- endif
-
- # Target directories
-@@ -42,7 +42,7 @@
- # Compilation specifics
-
- CC=gcc
--COPTFLAGS=-O2
-+COPTFLAGS=-O2
- DEBUG=-g #-DDEBUG
- WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \
- -Wpointer-arith -Wcast-qual -Wcast-align \
---- libcap-1.10.orig/Makefile
-+++ libcap-1.10/Makefile
-@@ -3,17 +3,20 @@
- #
- # Makefile for libcap
-
-+ifndef topdir
- topdir=$(shell pwd)
--include Make.Rules
-+endif
-+include $(topdir)/Make.Rules
-+DESTDIR=
-
- #
- # flags
- #
-
- all install clean: %: %-here
-- make -C libcap $(MAKE_DEFS) $@
-- make -C progs $(MAKE_DEFS) $@
-- make -C doc $(MAKE_DEFS) $@
-+ make -C $(topdir)/libcap $(MAKE_DEFS) $@
-+ make -C $(topdir)/progs $(MAKE_DEFS) $@
-+ make -C $(topdir)/doc $(MAKE_DEFS) $@
-
- all-here:
-
---- libcap-1.10.orig/libcap/include/sys/capability.h
-+++ libcap-1.10/libcap/include/sys/capability.h
-@@ -21,7 +21,288 @@
- */
-
- #include <sys/types.h>
--#include <linux/capability.h>
-+/*
-+ * This is <linux/capability.h>
-+ *
-+ * Andrew G. Morgan <morgan@transmeta.com>
-+ * Alexander Kjeldaas <astor@guardian.no>
-+ * with help from Aleph1, Roland Buresund and Andrew Main.
-+ *
-+ * See here for the libcap library ("POSIX draft" compliance):
-+ *
-+ * ftp://linux.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
-+ */
-+
-+#ifndef _LINUX_CAPABILITY_H
-+#define _LINUX_CAPABILITY_H
-+
-+#include <linux/types.h>
-+/*#include <linux/fs.h>*/
-+
-+/* User-level do most of the mapping between kernel and user
-+ capabilities based on the version tag given by the kernel. The
-+ kernel might be somewhat backwards compatible, but don't bet on
-+ it. */
-+
-+/* XXX - Note, cap_t, is defined by POSIX to be an "opaque" pointer to
-+ a set of three capability sets. The transposition of 3*the
-+ following structure to such a composite is better handled in a user
-+ library since the draft standard requires the use of malloc/free
-+ etc.. */
-+
-+#define _LINUX_CAPABILITY_VERSION 0x19980330
-+
-+typedef struct __user_cap_header_struct {
-+ __u32 version;
-+ int pid;
-+} *cap_user_header_t;
-+
-+typedef struct __user_cap_data_struct {
-+ __u32 effective;
-+ __u32 permitted;
-+ __u32 inheritable;
-+} *cap_user_data_t;
-+
-+#ifdef __KERNEL__
-+
-+/* #define STRICT_CAP_T_TYPECHECKS */
-+
-+#ifdef STRICT_CAP_T_TYPECHECKS
-+
-+typedef struct kernel_cap_struct {
-+ __u32 cap;
-+} kernel_cap_t;
-+
-+#else
-+
-+typedef __u32 kernel_cap_t;
-+
-+#endif
-+
-+#define _USER_CAP_HEADER_SIZE (2*sizeof(__u32))
-+#define _KERNEL_CAP_T_SIZE (sizeof(kernel_cap_t))
-+
-+#endif
-+
-+
-+/**
-+ ** POSIX-draft defined capabilities.
-+ **/
-+
-+/* In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this
-+ overrides the restriction of changing file ownership and group
-+ ownership. */
-+
-+#define CAP_CHOWN 0
-+
-+/* Override all DAC access, including ACL execute access if
-+ [_POSIX_ACL] is defined. Excluding DAC access covered by
-+ CAP_LINUX_IMMUTABLE. */
-+
-+#define CAP_DAC_OVERRIDE 1
-+
-+/* Overrides all DAC restrictions regarding read and search on files
-+ and directories, including ACL restrictions if [_POSIX_ACL] is
-+ defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */
-+
-+#define CAP_DAC_READ_SEARCH 2
-+
-+/* Overrides all restrictions about allowed operations on files, where
-+ file owner ID must be equal to the user ID, except where CAP_FSETID
-+ is applicable. It doesn't override MAC and DAC restrictions. */
-+
-+#define CAP_FOWNER 3
-+
-+/* Overrides the following restrictions that the effective user ID
-+ shall match the file owner ID when setting the S_ISUID and S_ISGID
-+ bits on that file; that the effective group ID (or one of the
-+ supplementary group IDs) shall match the file owner ID when setting
-+ the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are
-+ cleared on successful return from chown(2) (not implemented). */
-+
-+#define CAP_FSETID 4
-+
-+/* Used to decide between falling back on the old suser() or fsuser(). */
-+
-+#define CAP_FS_MASK 0x1f
-+
-+/* Overrides the restriction that the real or effective user ID of a
-+ process sending a signal must match the real or effective user ID
-+ of the process receiving the signal. */
-+
-+#define CAP_KILL 5
-+
-+/* Allows setgid(2) manipulation */
-+/* Allows setgroups(2) */
-+/* Allows forged gids on socket credentials passing. */
-+
-+#define CAP_SETGID 6
-+
-+/* Allows set*uid(2) manipulation (including fsuid). */
-+/* Allows forged pids on socket credentials passing. */
-+
-+#define CAP_SETUID 7
-+
-+
-+/**
-+ ** Linux-specific capabilities
-+ **/
-+
-+/* Transfer any capability in your permitted set to any pid,
-+ remove any capability in your permitted set from any pid */
-+
-+#define CAP_SETPCAP 8
-+
-+/* Allow modification of S_IMMUTABLE and S_APPEND file attributes */
-+
-+#define CAP_LINUX_IMMUTABLE 9
-+
-+/* Allows binding to TCP/UDP sockets below 1024 */
-+/* Allows binding to ATM VCIs below 32 */
-+
-+#define CAP_NET_BIND_SERVICE 10
-+
-+/* Allow broadcasting, listen to multicast */
-+
-+#define CAP_NET_BROADCAST 11
-+
-+/* Allow interface configuration */
-+/* Allow administration of IP firewall, masquerading and accounting */
-+/* Allow setting debug option on sockets */
-+/* Allow modification of routing tables */
-+/* Allow setting arbitrary process / process group ownership on
-+ sockets */
-+/* Allow binding to any address for transparent proxying */
-+/* Allow setting TOS (type of service) */
-+/* Allow setting promiscuous mode */
-+/* Allow clearing driver statistics */
-+/* Allow multicasting */
-+/* Allow read/write of device-specific registers */
-+/* Allow activation of ATM control sockets */
-+
-+#define CAP_NET_ADMIN 12
-+
-+/* Allow use of RAW sockets */
-+/* Allow use of PACKET sockets */
-+
-+#define CAP_NET_RAW 13
-+
-+/* Allow locking of shared memory segments */
-+/* Allow mlock and mlockall (which doesn't really have anything to do
-+ with IPC) */
-+
-+#define CAP_IPC_LOCK 14
-+
-+/* Override IPC ownership checks */
-+
-+#define CAP_IPC_OWNER 15
-+
-+/* Insert and remove kernel modules - modify kernel without limit */
-+/* Modify cap_bset */
-+#define CAP_SYS_MODULE 16
-+
-+/* Allow ioperm/iopl access */
-+/* Allow sending USB messages to any device via /proc/bus/usb */
-+
-+#define CAP_SYS_RAWIO 17
-+
-+/* Allow use of chroot() */
-+
-+#define CAP_SYS_CHROOT 18
-+
-+/* Allow ptrace() of any process */
-+
-+#define CAP_SYS_PTRACE 19
-+
-+/* Allow configuration of process accounting */
-+
-+#define CAP_SYS_PACCT 20
-+
-+/* Allow configuration of the secure attention key */
-+/* Allow administration of the random device */
-+/* Allow examination and configuration of disk quotas */
-+/* Allow configuring the kernel's syslog (printk behaviour) */
-+/* Allow setting the domainname */
-+/* Allow setting the hostname */
-+/* Allow calling bdflush() */
-+/* Allow mount() and umount(), setting up new smb connection */
-+/* Allow some autofs root ioctls */
-+/* Allow nfsservctl */
-+/* Allow VM86_REQUEST_IRQ */
-+/* Allow to read/write pci config on alpha */
-+/* Allow irix_prctl on mips (setstacksize) */
-+/* Allow flushing all cache on m68k (sys_cacheflush) */
-+/* Allow removing semaphores */
-+/* Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores
-+ and shared memory */
-+/* Allow locking/unlocking of shared memory segment */
-+/* Allow turning swap on/off */
-+/* Allow forged pids on socket credentials passing */
-+/* Allow setting readahead and flushing buffers on block devices */
-+/* Allow setting geometry in floppy driver */
-+/* Allow turning DMA on/off in xd driver */
-+/* Allow administration of md devices (mostly the above, but some
-+ extra ioctls) */
-+/* Allow tuning the ide driver */
-+/* Allow access to the nvram device */
-+/* Allow administration of apm_bios, serial and bttv (TV) device */
-+/* Allow manufacturer commands in isdn CAPI support driver */
-+/* Allow reading non-standardized portions of pci configuration space */
-+/* Allow DDI debug ioctl on sbpcd driver */
-+/* Allow setting up serial ports */
-+/* Allow sending raw qic-117 commands */
-+/* Allow enabling/disabling tagged queuing on SCSI controllers and sending
-+ arbitrary SCSI commands */
-+/* Allow setting encryption key on loopback filesystem */
-+
-+#define CAP_SYS_ADMIN 21
-+
-+/* Allow use of reboot() */
-+
-+#define CAP_SYS_BOOT 22
-+
-+/* Allow raising priority and setting priority on other (different
-+ UID) processes */
-+/* Allow use of FIFO and round-robin (realtime) scheduling on own
-+ processes and setting the scheduling algorithm used by another
-+ process. */
-+
-+#define CAP_SYS_NICE 23
-+
-+/* Override resource limits. Set resource limits. */
-+/* Override quota limits. */
-+/* Override reserved space on ext2 filesystem */
-+/* NOTE: ext2 honors fsuid when checking for resource overrides, so
-+ you can override using fsuid too */
-+/* Override size restrictions on IPC message queues */
-+/* Allow more than 64hz interrupts from the real-time clock */
-+/* Override max number of consoles on console allocation */
-+/* Override max number of keymaps */
-+
-+#define CAP_SYS_RESOURCE 24
-+
-+/* Allow manipulation of system clock */
-+/* Allow irix_stime on mips */
-+/* Allow setting the real-time clock */
-+
-+#define CAP_SYS_TIME 25
-+
-+/* Allow configuration of tty devices */
-+/* Allow vhangup() of tty */
-+
-+#define CAP_SYS_TTY_CONFIG 26
-+
-+/* Allow the privileged aspects of mknod() */
-+
-+#define CAP_MKNOD 27
-+
-+/* Allow taking of leases on files */
-+
-+#define CAP_LEASE 28
-+
-+#endif /* !_LINUX_CAPABILITY_H */
-+
-+
-
- /*
- * POSIX capability types
---- libcap-1.10.orig/libcap/Makefile
-+++ libcap-1.10/libcap/Makefile
-@@ -24,12 +24,15 @@
- #
- # defines
- #
-+ifndef $(topdir)
- topdir=$(shell pwd)/..
--include ../Make.Rules
-+endif
-+include $(topdir)/Make.Rules
-+
- #
- # Library version
- #
--LIBNAME=libcap.so
-+LIBNAME=libcap
- #
-
- FILES=cap_alloc cap_proc cap_extint cap_flag cap_text cap_sys
-@@ -39,10 +42,11 @@
-
- INCLS=libcap.h cap_names.h $(INCS)
- OBJS=$(addsuffix .o, $(FILES))
--MAJLIBNAME=$(LIBNAME).$(VERSION)
-+LOBJS=$(addsuffix .lo, $(FILES))
-+MAJLIBNAME=$(LIBNAME).so.$(VERSION)
- MINLIBNAME=$(MAJLIBNAME).$(MINOR)
-
--all: $(MINLIBNAME)
-+all: $(MINLIBNAME) $(LIBNAME).a
-
- _makenames: _makenames.c cap_names.sed
- $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
-@@ -50,31 +54,38 @@
- cap_names.h: _makenames
- ./_makenames > cap_names.h
-
--cap_names.sed: Makefile /usr/include/linux/capability.h
-- @echo "=> making cap_names.c from <linux/capability.h>"
-- @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define \([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
--# @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
-+cap_names.sed: Makefile include/sys/capability.h
-+ @echo "=> making cap_names.c from <sys/capability.h>"
-+ @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define \([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < include/sys/capability.h | fgrep -v 0x > cap_names.sed # @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
-+
-+$(LIBNAME).a: $(OBJS)
-+ ar cruv $(LIBNAME).a $(OBJS)
-
--$(MINLIBNAME): $(OBJS)
-- $(LD) -soname $(MAJLIBNAME) -x -shared -o $@ $(OBJS)
-+$(MINLIBNAME): $(LOBJS)
-+ $(CC) -shared -fPIC -Wl,-soname,$(MAJLIBNAME) -o $@ $(LOBJS)
- ln -sf $(MINLIBNAME) $(MAJLIBNAME)
-- ln -sf $(MAJLIBNAME) $(LIBNAME)
-+ ln -sf $(MAJLIBNAME) $(LIBNAME).so
-
- %.o: %.c $(INCLS)
- $(CC) $(CFLAGS) -c $< -o $@
-
-+%.lo: %.c $(INCLS)
-+ $(CC) $(CFLAGS) -fPIC -c $< -o $@
-+
-+
- install: all
- mkdir -p -m 0755 $(INCDIR)/sys
- install -m 0644 include/sys/capability.h $(INCDIR)/sys
- mkdir -p -m 0755 $(LIBDIR)
-+ install -m 0644 $(LIBNAME).a $(LIBDIR)
- install -m 0644 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME)
- ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME)
-- ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME)
-+ ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME).so
- -/sbin/ldconfig
-
- clean:
- $(LOCALCLEAN)
-- rm -f $(OBJS) $(LIBNAME)*
-+ rm -f $(OBJS) $(LOBJS) $(LIBNAME).a $(LIBNAME).so*
- rm -f cap_names.h cap_names.sed _makenames
- cd include/sys && $(LOCALCLEAN)
-
---- libcap-1.10.orig/libcap/_makenames.c
-+++ libcap-1.10/libcap/_makenames.c
-@@ -9,7 +9,7 @@
-
- #include <stdio.h>
- #include <stdlib.h>
--#include <linux/capability.h>
-+#include <sys/capability.h>
-
- /*
- * #include 'sed' generated array
---- libcap-1.10.orig/libcap/cap_sys.c
-+++ libcap-1.10/libcap/cap_sys.c
-@@ -10,7 +10,8 @@
- #include "libcap.h"
- #define __LIBRARY__
- #include <linux/unistd.h>
--
-+/* glic >= 2.1 knows capset/capget. no need to define it here */
-+/*
- _syscall2(int, capget,
- cap_user_header_t, header,
- cap_user_data_t, data)
-@@ -18,7 +19,7 @@
- _syscall2(int, capset,
- cap_user_header_t, header,
- const cap_user_data_t, data)
--
-+*/
- /*
- * $Log: libcap-1.10-debian.patch,v $
- * Revision 1.1 2006/10/29 23:14:00 jgc
- * upgpkg: libcap 1.10-2
- * Remove amd64 patches that messed things up
- * Apply debian patch to make it build again
- * Remove empty man2 directory the right way
- *
- * Revision 1.1.1.1 1999/04/17 22:16:31 morgan
---- libcap-1.10.orig/capfaq-0.2.txt
-+++ libcap-1.10/capfaq-0.2.txt
-@@ -0,0 +1,264 @@
-+This is the Linux kernel capabilities FAQ
-+
-+Its history, to the extent that I am able to reconstruct it is that
-+v2.0 was posted to the Linux kernel list on 1999/04/02 by Boris
-+Tobotras. Thanks to Denis Ducamp for forwarding me a copy.
-+
-+Cheers
-+
-+Andrew
-+
-+Linux Capabilities FAQ 0.2
-+==========================
-+
-+1) What is a capability?
-+
-+The name "capabilities" as used in the Linux kernel can be confusing.
-+First there are Capabilities as defined in computer science. A
-+capability is a token used by a process to prove that it is allowed to
-+do an operation on an object. The capability identifies the object
-+and the operations allowed on that object. A file descriptor is a
-+capability. You create the file descriptor with the "open" call and
-+request read or write permissions. Later, when doing a read or write
-+operation, the kernel uses the file descriptor as an index into a
-+data structure that indicates what operations are allowed. This is an
-+efficient way to check permissions. The necessary data structures are
-+created once during the "open" call. Later read and write calls only
-+have to do a table lookup. Operations on capabilities include copying
-+capabilities, transferring capabilities between processes, modifying a
-+capability, and revoking a capability. Modifying a capability can be
-+something like taking a read-write filedescriptor and making it
-+read-only. A capability often has a notion of an "owner" which is
-+able to invalidate all copies and derived versions of a capability.
-+Entire OSes are based on this "capability" model, with varying degrees
-+of purity. There are other ways of implementing capabilities than the
-+file descriptor model - traditionally special hardware has been used,
-+but modern systems also use the memory management unit of the CPU.
-+
-+Then there is something quite different called "POSIX capabilities"
-+which is what Linux uses. These capabilities are a partitioning of
-+the all powerful root privilege into a set of distinct privileges (but
-+look at securelevel emulation to find out that this isn't necessary
-+the whole truth). Users familiar with VMS or "Trusted" versions of
-+other UNIX variants will know this under the name "privileges". The
-+name "capabilities" comes from the now defunct POSIX draft 1003.1e
-+which used this name.
-+
-+2) So what is a "POSIX capability"?
-+
-+A process has three sets of bitmaps called the inheritable(I),
-+permitted(P), and effective(E) capabilities. Each capability is
-+implemented as a bit in each of these bitmaps which is either set or
-+unset. When a process tries to do a privileged operation, the
-+operating system will check the appropriate bit in the effective set
-+of the process (instead of checking whether the effective uid of the
-+process i 0 as is normally done). For example, when a process tries
-+to set the clock, the Linux kernel will check that the process has the
-+CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.
-+
-+The permitted set of the process indicates the capabilities the
-+process can use. The process can have capabilities set in the
-+permitted set that are not in the effective set. This indicates that
-+the process has temporarily disabled this capability. A process is
-+allowed to set a bit in its effective set only if it is available in
-+the permitted set. The distinction between effective and permitted
-+exists so that processes can "bracket" operations that need privilege.
-+
-+The inheritable capabilities are the capabilities of the current
-+process that should be inherited by a program executed by the current
-+process. The permitted set of a process is masked against the
-+inheritable set during exec(). Nothing special happens during fork()
-+or clone(). Child processes and threads are given an exact copy of
-+the capabilities of the parent process.
-+
-+3) What about other entities in the system? Users, Groups, Files?
-+
-+Files have capabilities. Conceptually they have the same three
-+bitmaps that processes have, but to avoid confusion we call them by
-+other names. Only executable files have capabilities, libraries don't
-+have capabilities (yet). The three sets are called the allowed set,
-+the forced set, and the effective set.
-+
-+The allowed set indicates what capabilities the executable is allowed
-+to receive from an execing process. This means that during exec(),
-+the capabilities of the old process are first masked against a set
-+which indicates what the process gives away (the inheritable set of
-+the process), and then they are masked against a set which indicates
-+what capabilities the new process image is allowed to receive (the
-+allowed set of the executable).
-+
-+The forced set is a set of capabilities created out of thin air and
-+given to the process after execing the executable. The forced set is
-+similar in nature to the setuid feature. In fact, the setuid bit from
-+the filesystem is "read" as a full forced set by the kernel.
-+
-+The effective set indicates which bits in the permitted set of the new
-+process should be transferred to the effective set of the new process.
-+The effective set is best thought of as a "capability aware" set. It
-+should consist of only 1s if the executable is capability-dumb, or
-+only 0s if the executable is capability-smart. Since the effective
-+set consists of only 0s or only 1s, the filesystem can implement this
-+set using a single bit.
-+
-+NOTE: Filesystem support for capabilities is not part of Linux 2.2.
-+
-+Users and Groups don't have associated capabilities from the kernel's
-+point of view, but it is entirely reasonable to associate users or
-+groups with capabilities. By letting the "login" program set some
-+capabilities it is possible to make role users such as a backup user
-+that will have the CAP_DAC_READ_SEARCH capability and be able to do
-+backups. This could also be implemented as a PAM module, but nobody
-+has implemented one yet.
-+
-+4) What capabilities exist?
-+
-+The capabilities available in Linux are listed and documented in the
-+file /usr/src/linux/include/linux/capability.h.
-+
-+5) Are Linux capabilities hierarchical?
-+
-+No, you cannot make a "subcapability" out of a Linux capability as in
-+capability-based OSes.
-+
-+6) How can I use capabilities to make sure Mr. Evil Luser (eluser)
-+can't exploit my "suid" programs?
-+
-+This is the general outline of how this works given filesystem
-+capability support exists. First, you have a PAM module that sets the
-+inheritable capabilities of the login-shell of eluser. Then for all
-+"suid" programs on the system, you decide what capabilities they need
-+and set the _allowed_ set of the executable to that set of
-+capabilities. The capability rules
-+
-+ new permitted = forced | (allowed & inheritable)
-+
-+means that you should be careful about setting forced capabilities on
-+executables. In a few cases, this can be useful though. For example
-+the login program needs to set the inheritable set of the new user and
-+therefore needs an almost full permitted set. So if you want eluser
-+to be able to run login and log in as a different user, you will have
-+to set some forced bits on that executable.
-+
-+7) What about passing capabilities between processes?
-+
-+Currently this is done by the system call "setcap" which can set the
-+capabilities of another process. This requires the CAP_SETPCAP
-+capability which you really only want to grant a _few_ processes.
-+CAP_SETPCAP was originally intended as a workaround to be able to
-+implement filesystem support for capabilities using a daemon outside
-+the kernel.
-+
-+There has been discussions about implementing socket-level capability
-+passing. This means that you can pass a capability over a socket. No
-+support for this exists in the official kernel yet.
-+
-+8) I see securelevel has been removed from 2.2 and are superceeded by
-+capabilities. How do I emulate securelevel using capabilities?
-+
-+The setcap system call can remove a capability from _all_ processes on
-+the system in one atomic operation. The setcap utility from the
-+libcap distribution will do this for you. The utility requires the
-+CAP_SETPCAP privilege to do this. The CAP_SETPCAP capability is not
-+enabled by default.
-+
-+libcap is available from
-+ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
-+
-+9) I noticed that the capability.h file lacks some capabilities that
-+are needed to fully emulate 2.0 securelevel. Is there a patch for
-+this?
-+
-+Actually yes - funny you should ask :-). The problem with 2.0
-+securelevel is that they for example stop root from accessing block
-+devices. At the same time they restrict the use of iopl. These two
-+changes are fundamentally different. Blocking access to block devices
-+means restricting something that usually isn't restricted.
-+Restricting access to the use of iopl on the other hand means
-+restricting (blocking) access to something that is already blocked.
-+Emulating the parts of 2.0 securelevel that restricts things that are
-+normally not restricted means that the capabilites in the kernel has
-+to have a set of capabilities that are usually _on_ for a normal
-+process (note that this breaks the explanation that capabilities are a
-+partitioning of the root privileges). There is an experimental patch at
-+
-+ftp://ftp.guardian.no/pub/free/linux/capabilities/patch-cap-exp-1
-+
-+which implements a set of capabilities with the "CAP_USER" prefix:
-+
-+cap_user_sock - allowed to use socket()
-+cap_user_dev - allowed to open char/block devices
-+cap_user_fifo - allowed to use pipes
-+
-+These should be enough to emulate 2.0 securelevel (tell me if we need
-+something more).
-+
-+10) Seems I need a CAP_SETPCAP capability that I don't have to make use
-+of capabilities. How do I enable this capability?
-+
-+Change the definition of CAP_INIT_EFF_SET and CAP_INIT_INH_SET to the
-+following in include/linux/capability.h:
-+
-+#define CAP_INIT_EFF_SET { ~0 }
-+#define CAP_INIT_INH_SET { ~0 }
-+
-+This will start init with a full capability set and not with
-+CAP_SETPCAP removed.
-+
-+11) How do I start a process with a limited set of capabilities?
-+
-+Get the libcap library and use the execcap utility. The following
-+example starts the update daemon with only the CAP_SYS_ADMIN
-+capability.
-+
-+execcap 'cap_sys_admin=eip' update
-+
-+12) How do I start a process with a limited set of capabilities under
-+another uid?
-+
-+Use the sucap utility which changes uid from root without loosing any
-+capabilities. Normally all capabilities are cleared when changing uid
-+from root. The sucap utility requires the CAP_SETPCAP capability.
-+The following example starts updated under uid updated and gid updated
-+with CAP_SYS_ADMIN raised in the Effective set.
-+
-+sucap updated updated execcap 'cap_sys_admin=eip' update
-+
-+[ Sucap is currently available from
-+ftp://ftp.guardian.no/pub/free/linux/capabilities/sucap.c. Put it in
-+the progs directory of libcap to compile.]
-+
-+13) What are the "capability rules"
-+
-+The capability rules are the rules used to set the capabilities of the
-+new process image after an exec. They work like this:
-+
-+ pI' = pI
-+ (***) pP' = fP | (fI & pI)
-+ pE' = pP' & fE [NB. fE is 0 or ~0]
-+
-+ I=Inheritable, P=Permitted, E=Effective // p=process, f=file
-+ ' indicates post-exec().
-+
-+Now to make sense of the equations think of fP as the Forced set of
-+the executable, and fI as the Allowed set of the executable. Notice
-+how the Inheritable set isn't touched at all during exec().
-+
-+14) What are the laws for setting capability bits in the Inheritable,
-+Permitted, and Effective sets?
-+
-+Bits can be transferred from Permitted to either Effective or
-+Inheritable set.
-+
-+Bits can be removed from all sets.
-+
-+15) Where is the standard on which the Linux capabilities are based?
-+
-+There used to be a POSIX draft called POSIX.6 and later POSIX 1003.1e.
-+However after the committee had spent over 10 years, POSIX decided
-+that enough is enough and dropped the draft. There will therefore not
-+be a POSIX standard covering security anytime soon. This may lead to
-+that the POSIX draft is available for free, however.
-+
-+--
-+ Best regards, -- Boris.
-+