summaryrefslogtreecommitdiffstats
path: root/abs/core-testing/libcap
diff options
context:
space:
mode:
authorJames Meyer <James.meyer@operamail.com>2008-10-02 03:19:12 (GMT)
committerJames Meyer <James.meyer@operamail.com>2008-10-02 03:19:12 (GMT)
commit0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a (patch)
treec0aa2c0b53c317be87eacfcb77b63f53f1f415e7 /abs/core-testing/libcap
downloadlinhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.zip
linhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.tar.gz
linhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.tar.bz2
initial import
Diffstat (limited to 'abs/core-testing/libcap')
-rw-r--r--abs/core-testing/libcap/PKGBUILD20
-rw-r--r--abs/core-testing/libcap/libcap-1.10-debian.patch766
-rw-r--r--abs/core-testing/libcap/libcap-1.10-fixcflags.patch22
-rw-r--r--abs/core-testing/libcap/libcap-1.10-shared.patch17
4 files changed, 825 insertions, 0 deletions
diff --git a/abs/core-testing/libcap/PKGBUILD b/abs/core-testing/libcap/PKGBUILD
new file mode 100644
index 0000000..8d09b19
--- /dev/null
+++ b/abs/core-testing/libcap/PKGBUILD
@@ -0,0 +1,20 @@
+#$Id: PKGBUILD 8870 2008-08-16 22:39:56Z eric $
+# Maintainer: Arjan Timmerman <arjan@archlinux.org>
+pkgname=libcap
+pkgver=1.10
+pkgrel=2
+pkgdesc="POSIX 1003.1e capabilities"
+arch=(i686 x86_64)
+url="http://www.kernel.org/pub/linux/libs/security/linux-privs/"
+license="GPL"
+depends=('glibc')
+source=(http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/${pkgname}-${pkgver}.tar.gz
+ libcap-1.10-debian.patch)
+md5sums=('2c09eea823f67cfdde96177a959bc39b' 'ba642c86c4072917fcff77ec31411194')
+
+build() {
+ cd ${startdir}/src/${pkgname}-${pkgver}
+ patch -Np1 -i ${startdir}/src/libcap-1.10-debian.patch || return 1
+ make prefix=/usr DESTDIR=${startdir}/pkg install
+ rmdir ${startdir}/pkg/usr/share/man/man2
+}
diff --git a/abs/core-testing/libcap/libcap-1.10-debian.patch b/abs/core-testing/libcap/libcap-1.10-debian.patch
new file mode 100644
index 0000000..26d57ec
--- /dev/null
+++ b/abs/core-testing/libcap/libcap-1.10-debian.patch
@@ -0,0 +1,766 @@
+--- 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.
++
diff --git a/abs/core-testing/libcap/libcap-1.10-fixcflags.patch b/abs/core-testing/libcap/libcap-1.10-fixcflags.patch
new file mode 100644
index 0000000..3566d95
--- /dev/null
+++ b/abs/core-testing/libcap/libcap-1.10-fixcflags.patch
@@ -0,0 +1,22 @@
+diff -Naur libcap-1.10.orig/Make.Rules libcap-1.10/Make.Rules
+--- libcap-1.10.orig/Make.Rules 2005-05-30 16:10:07.000000000 +0000
++++ libcap-1.10/Make.Rules 2005-05-30 16:11:18.000000000 +0000
+@@ -42,8 +42,8 @@
+ # Compilation specifics
+
+ CC=gcc
+-COPTFLAGS=-O2
+-DEBUG=-g #-DDEBUG
++COPTFLAGS=-O2 -fPIC
++DEBUG=
+ WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \
+ -Wpointer-arith -Wcast-qual -Wcast-align \
+ -Wtraditional -Wstrict-prototypes -Wmissing-prototypes \
+@@ -54,7 +54,7 @@
+ IPATH=-I$(topdir)/libcap/include
+ INCS=$(topdir)/libcap/include/sys/capability.h
+ LIBS=-L$(topdir)/libcap -lcap
+-CFLAGS=-Dlinux $(WARNINGS) $(DEBUG) $(COPTFLAG) $(IPATH)
++CFLAGS+=-Dlinux $(WARNINGS) $(DEBUG) $(COPTFLAG) $(IPATH)
+
+ # Global cleanup stuff \ No newline at end of file
diff --git a/abs/core-testing/libcap/libcap-1.10-shared.patch b/abs/core-testing/libcap/libcap-1.10-shared.patch
new file mode 100644
index 0000000..54e5496
--- /dev/null
+++ b/abs/core-testing/libcap/libcap-1.10-shared.patch
@@ -0,0 +1,17 @@
+--- libcap-1.11/libcap/Makefile.shared 1999-04-17 18:16:31.000000000 -0400
++++ libcap-1.11/libcap/Makefile 2002-07-19 06:24:23.000000000 -0400
+@@ -56,12 +56,12 @@ cap_names.sed: Makefile /usr/include/lin
+ # @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
+
+ $(MINLIBNAME): $(OBJS)
+- $(LD) -soname $(MAJLIBNAME) -x -shared -o $@ $(OBJS)
++ $(CC) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS)
+ ln -sf $(MINLIBNAME) $(MAJLIBNAME)
+ ln -sf $(MAJLIBNAME) $(LIBNAME)
+
+ %.o: %.c $(INCLS)
+- $(CC) $(CFLAGS) -c $< -o $@
++ $(CC) $(CFLAGS) -fpic -c $< -o $@
+
+ install: all
+ mkdir -p -m 0755 $(INCDIR)/sys