libraries/libcap: Updated for version 1.97

8 files changed, 331 insertions, 33 deletions

diff --git a/libraries/libcap/README b/libraries/libcap/README
index 48b8ac021ffda..5922aa31f1403 100644
--- a/libraries/libcap/README
+++ b/libraries/libcap/README
@@ -1,4 +1,5 @@
-libcap is a library for getting and setting POSIX.1e (formerly POSIX 6) draft 15 capabilities.
+libcap is a library for getting and setting POSIX.1e 
+(formerly POSIX 6) draft 15 capabilities.
 
 More information (POSIX 1e and 2c drafts):  
 http://wt.xpilot.org/publications/posix.1e/download.html
@@ -6,8 +7,12 @@ http://wt.xpilot.org/publications/posix.1e/download.html
 Usage tutorial (Olaf Kirch: Using Capabilities - 2002): 
 http://www.lst.de/~okir/blackhats/node125.html 
 
-Linux Capabilities FAQ 0.2 (by Boris Tobotras - 1999):
-  ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt
+Active development of libcap v2 is in filesystem capabilities, see:
+http://www.kernel.org/pub/linux/libs/security/linux-privs/README
+
+And maybe read Serge E. Hallyn' article
+POSIX file capabilities: Parceling the power of root
+http://www.ibm.com/developerworks/linux/library/l-posixcap.html?ca=dgr-lnxw06LinuxPOSIX
 
 If you uninstall this package, you will need to manually remove the
 /usr/include/sys/capability.h header.
diff --git a/libraries/libcap/capfaq-0.2.txt b/libraries/libcap/capfaq-0.2.txt
new file mode 100644
index 0000000000000..e3e272be4741c
--- /dev/null
+++ b/libraries/libcap/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/libraries/libcap/doinst.sh b/libraries/libcap/doinst.sh
index c129647617fb4..107c5225b2416 100644
--- a/libraries/libcap/doinst.sh
+++ b/libraries/libcap/doinst.sh
@@ -1,10 +1,10 @@
 config() {
   NEW="$1"
-  OLD="`dirname $NEW`/`basename $NEW .new`"
+  OLD="$(dirname $NEW)/$(basename $NEW .new)"
   # If there's no config file by that name, mv it over:
   if [ ! -r $OLD ]; then
     mv $NEW $OLD
-  elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then
+  elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then
     # toss the redundant copy
     rm $NEW
   fi
diff --git a/libraries/libcap/libcap-1.97-i486.diff b/libraries/libcap/libcap-1.97-i486.diff
new file mode 100644
index 0000000000000..4995caaa2fb1a
--- /dev/null
+++ b/libraries/libcap/libcap-1.97-i486.diff
@@ -0,0 +1,12 @@
+diff -ur libcap-1.97/Make.Rules libcap-1.97.new/Make.Rules
+--- libcap-1.97/Make.Rules	2007-08-14 08:21:26.000000000 +0200
++++ libcap-1.97.new/Make.Rules	2007-10-29 12:35:31.000000000 +0100
+@@ -48,7 +48,7 @@
+ 
+ CC=gcc
+ COPTFLAGS=-O2
+-DEBUG=-O2 -g #-DDEBUG
++DEBUG=-O2 -march=i486 -mtune=i686 #-g #-DDEBUG
+ WARNINGS=-fPIC -D_POSIX_SOURCE -Wall -Wwrite-strings \
+         -Wpointer-arith -Wcast-qual -Wcast-align \
+         -Wstrict-prototypes -Wmissing-prototypes \
diff --git a/libraries/libcap/libcap-1.97-i686.diff b/libraries/libcap/libcap-1.97-i686.diff
new file mode 100644
index 0000000000000..e31239b9a9610
--- /dev/null
+++ b/libraries/libcap/libcap-1.97-i686.diff
@@ -0,0 +1,12 @@
+diff -ur libcap-1.97/Make.Rules libcap-1.97.new/Make.Rules
+--- libcap-1.97/Make.Rules	2007-08-14 08:21:26.000000000 +0200
++++ libcap-1.97.new/Make.Rules	2007-10-29 12:35:31.000000000 +0100
+@@ -48,7 +48,7 @@
+ 
+ CC=gcc
+ COPTFLAGS=-O2
+-DEBUG=-O2 -g #-DDEBUG
++DEBUG=-O2 -march=i686 -mtune=i686 #-g #-DDEBUG
+ WARNINGS=-fPIC -D_POSIX_SOURCE -Wall -Wwrite-strings \
+         -Wpointer-arith -Wcast-qual -Wcast-align \
+         -Wstrict-prototypes -Wmissing-prototypes \
diff --git a/libraries/libcap/libcap.SlackBuild b/libraries/libcap/libcap.SlackBuild
index 40ece77170bcd..dcf928bda6cca 100644
--- a/libraries/libcap/libcap.SlackBuild
+++ b/libraries/libcap/libcap.SlackBuild
@@ -5,21 +5,15 @@
 # Modified by the SlackBuilds.org project
 
 PRGNAM=libcap
-VERSION=1.10
+VERSION=1.97
 ARCH=${ARCH:-i486}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}
-CWD=`pwd`
+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"
-fi
-
 # Bail out if we have a problem
 set -e
 
@@ -27,15 +21,22 @@ rm -rf $PKG
 mkdir -p $TMP $PKG $OUTPUT
 cd $TMP 
 rm -rf $PRGNAM-$VERSION
-tar -xzvf $CWD/$PRGNAM-$VERSION.tar.gz || exit 1
+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
 
-CFLAGS="$SLKCFLAGS" make || exit 1
-make install FAKEROOT=$PKG || exit 1
+# Apply a patch to set the CFLAGS
+if [ "$ARCH" = "i686" ]; then
+  patch -p1 < $CWD/$PRGNAM-$VERSION-$ARCH.diff
+elif [ "$ARCH" = "i486" ]; then
+  patch -p1 < $CWD/$PRGNAM-$VERSION-$ARCH.diff
+fi
+
+make
+make install FAKEROOT=$PKG man_prefix=/usr
 
 ( cd $PKG
   find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
@@ -46,8 +47,12 @@ if [ -d $PKG/usr/man ]; then
   gzip -9 $PKG/usr/man/man?/*
 fi
 
+# Glibc already has the capget/capset manpage
+rm -rf $PKG/usr/man/man2
+
 mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
-cp -a README CHANGELOG License pgp.keys.asc doc/capability.notes \
+cp -a README CHANGELOG License pgp.keys.asc \
+  doc/capability.notes $CWD/capfaq-0.2.txt \
   $PKG/usr/doc/$PRGNAM-$VERSION
 cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
 
@@ -60,11 +65,4 @@ cat $CWD/slack-desc > $PKG/install/slack-desc
 cat $CWD/doinst.sh > $PKG/install/doinst.sh
 
 cd $PKG
-/sbin/makepkg -l y -c n -p $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.tgz
-
-# Clean up the extra stuff:
-if [ "$1" = "--cleanup" ]; then
-  rm -rf $TMP/$PRGNAM-$VERSION
-  rm -rf $PKG
-fi
-
+/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
index 6cfcd7aeb2d37..b22b834594c4c 100644
--- a/libraries/libcap/libcap.info
+++ b/libraries/libcap/libcap.info
@@ -1,8 +1,8 @@
 PRGNAM="libcap"
-VERSION="1.10"
+VERSION="1.97"
 HOMEPAGE="http://sourceforge.net/projects/linux-privs/"
-DOWNLOAD="ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/libcap-1.10.tar.gz"
-MD5SUM="2c09eea823f67cfdde96177a959bc39b"
+DOWNLOAD="ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/libcap-1.97.tar.gz"
+MD5SUM="0021ac30148844537e134512587691fb"
 MAINTAINER="Menno E. Duursma"
 EMAIL="druiloor@zonnet.nl"
-APPROVED="robw810"
+APPROVED="rworkman"
diff --git a/libraries/libcap/slack-desc b/libraries/libcap/slack-desc
index 9e01ff39638a8..0186863558432 100644
--- a/libraries/libcap/slack-desc
+++ b/libraries/libcap/slack-desc
@@ -1,12 +1,19 @@
-libcap: libcap 
+# 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. Morton; however, it would not
+libcap: Libcap was written by Andrew G. Morgan; however, it would not
 libcap: have been possible without the help of Aleph1, Roland Buresund,
 libcap: Andrew Main, and Alexander Kjeldaas.
 libcap:
-libcap: More information on capabilities in the Linux kernel can be found at
-libcap: http://www.kernel.org/pub/linux/libs/security/linux-privs/
+libcap:
 libcap: