libraries/libcap: Removed from 12.2 repository

5 files changed, 0 insertions, 403 deletions

diff --git a/libraries/libcap/README b/libraries/libcap/README
deleted file mode 100644
index 7d77ca7fc62f5..0000000000000
--- a/libraries/libcap/README
+++ /dev/null
@@ -1,31 +0,0 @@
-libcap is a library for getting and setting POSIX.1e 
-(formerly POSIX 6) draft 15 capabilities.
-
-libcap v2 implements support for filesystem capabilities; however,
-the kernel shipped with Slackware 12.1 does not support this.
-
-	# grep CAPABILITIES /boot/config
-	CONFIG_SECURITY_CAPABILITIES=y
-	# CONFIG_SECURITY_FILE_CAPABILITIES is not set
-
-To enable this support, recompile the kernel with this option set:
-
-	Security options  --->
-		Enable different security models
-			Default Linux Capabilities
-		File POSIX Capabilities (EXPERIMENTAL)
-
-Even if you don't use this, the actual lib should still be compatible
-with libcap v1 in the 12.0 repo. If, however, this happens to not actually
-be the case, the SlackBuild there should still work fine on 12.1.
-
-Additional URL pointers (besides the project homepage):
-
-POSIX file capabilities: Parceling the power of root by Serge E. Hallyn
-http://www.ibm.com/developerworks/linux/library/l-posixcap.html?ca=dgr-lnxw06LinuxPOSIX
-
-Using Capabilities by Olaf Kirch
-http://www.lst.de/~okir/blackhats/node125.html
-
-POSIX 1e and 2c drafts:
-http://wt.xpilot.org/publications/posix.1e/download.html
diff --git a/libraries/libcap/capfaq-0.2.txt b/libraries/libcap/capfaq-0.2.txt
deleted file mode 100644
index e3e272be4741c..0000000000000
--- a/libraries/libcap/capfaq-0.2.txt
+++ /dev/null
@@ -1,264 +0,0 @@
-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/libraries/libcap/libcap.SlackBuild b/libraries/libcap/libcap.SlackBuild
deleted file mode 100644
index d406089837e5b..0000000000000
--- a/libraries/libcap/libcap.SlackBuild
+++ /dev/null
@@ -1,81 +0,0 @@
-#!/bin/sh
-
-# Slackware build script for libcap
-
-# Written by Menno Duursma
-
-# This program is free software. It comes without any warranty.
-# Granted WTFPL, version 2, as published by Sam Hocevar dec 2004.
-# See http://sam.zoy.org/wtfpl/COPYING for more details.
-
-PRGNAM=libcap
-VERSION=2.14
-ARCH=${ARCH:-i486}
-BUILD=${BUILD:-1}
-TAG=${TAG:-_SBo}
-
-CWD=$(pwd)
-TMP=${TMP:-/tmp/SBo}
-PKG=$TMP/package-$PRGNAM
-OUTPUT=${OUTPUT:-/tmp}
-
-if [ "$ARCH" = "i486" ]; then
-  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
-elif [ "$ARCH" = "i686" ]; then
-  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
-elif [ "$ARCH" = "x86_64" ]; then
-  SLKCFLAGS="-O2 -fPIC"
-fi
-
-set -e # Bail out if we have a problem
-
-rm -rf $PKG
-mkdir -p $TMP $PKG $OUTPUT
-cd $TMP 
-rm -rf $PRGNAM-$VERSION
-tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
-cd $PRGNAM-$VERSION
-chown -R root:root .
-find . -type d | xargs chmod 0755
-find . -type f | xargs chmod go-w
-
-# We use DEBUG for the CFLAGS setting as that works in one take
-sed -i.orig "s/^\(DEBUG =\).*/\1$SLKCFLAGS/" Make.Rules
-
-make DYNAMIC=yes
-make install FAKEROOT=$PKG man_prefix=/usr
-
-# Add included scripts
-( cd contrib || exit 1
-  for file in pcaps4convenience pcaps4server pcaps4suid0 ; do
-    install -m 0755 -D $file $PKG/usr/sbin/$file ; done
-)
-
-find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
-  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true
-
-( cd $PKG/usr/man || exit 1
-  find . -type f -exec gzip -9 {} \;
-  for i in $(find . -type l) ; do
-    ln -s $(readlink $i).gz $i.gz ; rm $i ; done
-)
-
-# glibc already has the capget/capset manpage
-rm -rf $PKG/usr/man/man2
-
-mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
-cp -a CHANGELOG README License $CWD/capfaq-0.2.txt \
-  pgp.keys.asc doc/capability.notes progs/quicktest.sh \
-    $PKG/usr/doc/$PRGNAM-$VERSION
-cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
-cat $CWD/README > $PKG/usr/doc/$PRGNAM-$VERSION/README.$TAG
-
-# Fix privs, just to make sure
-chown -R root:root $PKG/usr/doc
-find $PKG/usr/doc -type f -exec chmod 644 {} \;
-
-mkdir -p $PKG/install
-cat $CWD/slack-desc > $PKG/install/slack-desc
-
-cd $PKG
-/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.tgz
diff --git a/libraries/libcap/libcap.info b/libraries/libcap/libcap.info
deleted file mode 100644
index 6a8492a942ee3..0000000000000
--- a/libraries/libcap/libcap.info
+++ /dev/null
@@ -1,8 +0,0 @@
-PRGNAM="libcap"
-VERSION="2.14"
-HOMEPAGE="http://sites.google.com/site/fullycapable/"
-DOWNLOAD="http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.14.tar.gz"
-MD5SUM="bdebad7e0b904bd4e20c321bd48100cc"
-MAINTAINER="Menno E. Duursma"
-EMAIL="druiloor@zonnet.nl"
-APPROVED="rworkman"
diff --git a/libraries/libcap/slack-desc b/libraries/libcap/slack-desc
deleted file mode 100644
index 50bacc3024824..0000000000000
--- a/libraries/libcap/slack-desc
+++ /dev/null
@@ -1,19 +0,0 @@
-# HOW TO EDIT THIS FILE:
-# The "handy ruler" below makes it easier to edit a package description.  Line
-# up the first '|' above the ':' following the base package name, and the '|'
-# on the right side marks the last column you can put a character in.  You must
-# make exactly 11 lines for the formatting to be correct.  It's also
-# customary to leave one space after the ':'.
-
-      |-----handy-ruler------------------------------------------------------|
-libcap: libcap (get/set POSIX capabilities)
-libcap:
-libcap: This is a library for getting and setting POSIX.1e (formerly POSIX 6)
-libcap: draft 15 capabilities.
-libcap:
-libcap: Libcap was written by Andrew G. Morgan
-libcap:
-libcap:
-libcap:
-libcap:
-libcap: