diff --git a/.compat-libcap1.metadata b/.compat-libcap1.metadata new file mode 100644 index 0000000..2edd786 --- /dev/null +++ b/.compat-libcap1.metadata @@ -0,0 +1 @@ +95e86a451df60db26152f753ed5f880d42a41884 SOURCES/libcap-1.10.tar.gz diff --git a/README.md b/README.md deleted file mode 100644 index 0e7897f..0000000 --- a/README.md +++ /dev/null @@ -1,5 +0,0 @@ -The master branch has no content - -Look at the c7 branch if you are working with CentOS-7, or the c4/c5/c6 branch for CentOS-4, 5 or 6 - -If you find this file in a distro specific branch, it means that no content has been checked in yet diff --git a/SOURCES/capfaq-0.2.txt b/SOURCES/capfaq-0.2.txt new file mode 100644 index 0000000..e3e272b --- /dev/null +++ b/SOURCES/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/SOURCES/libcap-1.10-alpha.patch b/SOURCES/libcap-1.10-alpha.patch new file mode 100644 index 0000000..d0cadf9 --- /dev/null +++ b/SOURCES/libcap-1.10-alpha.patch @@ -0,0 +1,11 @@ +--- libcap-1.10/libcap/_makenames.c.foo Fri Nov 9 16:38:45 2001 ++++ libcap-1.10/libcap/_makenames.c Fri Nov 9 16:39:30 2001 +@@ -9,7 +9,7 @@ + + #include + #include +-#include ++#include "include/sys/capability.h" + + /* + * #include 'sed' generated array diff --git a/SOURCES/libcap-1.10-ia64.patch b/SOURCES/libcap-1.10-ia64.patch new file mode 100644 index 0000000..bc572f5 --- /dev/null +++ b/SOURCES/libcap-1.10-ia64.patch @@ -0,0 +1,34 @@ +diff -up libcap-1.10/libcap/cap_sys.c.ia64 libcap-1.10/libcap/cap_sys.c +--- libcap-1.10/libcap/cap_sys.c.ia64 1999-04-18 00:16:31.000000000 +0200 ++++ libcap-1.10/libcap/cap_sys.c 2012-10-17 22:34:16.059369216 +0200 +@@ -11,14 +11,6 @@ + #define __LIBRARY__ + #include + +-_syscall2(int, capget, +- cap_user_header_t, header, +- cap_user_data_t, data) +- +-_syscall2(int, capset, +- cap_user_header_t, header, +- const cap_user_data_t, data) +- + /* + * $Log: cap_sys.c,v $ + * Revision 1.1.1.1 1999/04/17 22:16:31 morgan +diff -up libcap-1.10/Make.Rules.ia64 libcap-1.10/Make.Rules +--- libcap-1.10/Make.Rules.ia64 1999-11-18 07:06:02.000000000 +0100 ++++ libcap-1.10/Make.Rules 2012-10-17 22:32:23.477360230 +0200 +@@ -44,10 +44,10 @@ MINOR=10 + CC=gcc + COPTFLAGS=-O2 + DEBUG=-g #-DDEBUG +-WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \ ++WARNINGS=-D_POSIX_SOURCE -Wall -Wwrite-strings \ + -Wpointer-arith -Wcast-qual -Wcast-align \ + -Wtraditional -Wstrict-prototypes -Wmissing-prototypes \ +- -Wnested-externs -Winline -Wshadow -pedantic ++ -Wnested-externs -Winline -Wshadow + LD=ld + LDFLAGS=-s #-g + diff --git a/SOURCES/libcap-1.10-shared.patch b/SOURCES/libcap-1.10-shared.patch new file mode 100644 index 0000000..54e5496 --- /dev/null +++ b/SOURCES/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 diff --git a/SOURCES/libcap-1.10-types.patch b/SOURCES/libcap-1.10-types.patch new file mode 100644 index 0000000..97e4118 --- /dev/null +++ b/SOURCES/libcap-1.10-types.patch @@ -0,0 +1,10 @@ +--- libcap-1.10/libcap/include/sys/capability.h 2010-08-17 20:55:28.000000000 +0200 ++++ libcap-1.10_/libcap/include/sys/capability.h 2010-08-17 20:54:41.000000000 +0200 +@@ -21,6 +21,7 @@ + */ + + #include ++#include + #include + + /* diff --git a/SOURCES/libcap-1.10-useCFLAGSwithCC.patch b/SOURCES/libcap-1.10-useCFLAGSwithCC.patch new file mode 100644 index 0000000..4fa83ad --- /dev/null +++ b/SOURCES/libcap-1.10-useCFLAGSwithCC.patch @@ -0,0 +1,22 @@ +--- libcap-1.10/libcap/Makefile.BAD 2006-07-13 20:42:35.000000000 -0400 ++++ libcap-1.10/libcap/Makefile 2006-07-13 20:42:53.000000000 -0400 +@@ -56,7 +56,7 @@ + # @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) +- $(CC) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS) ++ $(CC) $(COPTFLAG) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS) + ln -sf $(MINLIBNAME) $(MAJLIBNAME) + ln -sf $(MAJLIBNAME) $(LIBNAME) + +--- libcap-1.10/progs/Makefile.BAD 2006-07-13 20:48:44.000000000 -0400 ++++ libcap-1.10/progs/Makefile 2006-07-13 20:48:54.000000000 -0400 +@@ -36,7 +36,7 @@ + all: $(PROGS) + + $(PROGS): %: %.o +- $(CC) $(LDFLAGS) -o $@ $< $(LIBS) ++ $(CC) $(COPTFLAG) $(LDFLAGS) -o $@ $< $(LIBS) + + %.o: %.c $(INCS) + $(CC) $(CFLAGS) -c $< -o $@ diff --git a/SOURCES/libcap-1.10-userland.patch b/SOURCES/libcap-1.10-userland.patch new file mode 100644 index 0000000..0cd608f --- /dev/null +++ b/SOURCES/libcap-1.10-userland.patch @@ -0,0 +1,19 @@ +--- libcap-1.10/libcap/include/sys/capability.h.foo Fri Nov 9 16:26:25 2001 ++++ libcap-1.10/libcap/include/sys/capability.h Fri Nov 9 16:28:47 2001 +@@ -21,6 +21,16 @@ + */ + + #include ++#include ++ ++/* ++ * Make sure we can be included from userland by preventing ++ * capability.h from including other kernel headers ++ */ ++#define _LINUX_TYPES_H ++#define _LINUX_FS_H ++typedef unsigned int __u32; ++ + #include + + /* diff --git a/SPECS/compat-libcap1.spec b/SPECS/compat-libcap1.spec new file mode 100644 index 0000000..f25e045 --- /dev/null +++ b/SPECS/compat-libcap1.spec @@ -0,0 +1,178 @@ +Name: compat-libcap1 +Version: 1.10 +Release: 3%{?dist} +Summary: Library for getting and setting POSIX.1e capabilities +Source: ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/libcap-1.10.tar.gz +Source1: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt +License: BSD-like and LGPL +Patch: libcap-1.10-ia64.patch +Patch1: libcap-1.10-userland.patch +Patch2: libcap-1.10-shared.patch +Patch3: libcap-1.10-alpha.patch +Patch4: libcap-1.10-useCFLAGSwithCC.patch +Patch5: libcap-1.10-types.patch +Group: System Environment/Libraries +BuildRoot: %{_tmppath}/%{name}-%{version}-root + +%description +libcap is a library for getting and setting POSIX.1e (formerly POSIX 6) +draft 15 capabilities. + +%prep +%setup -q -n libcap-1.10 +# FIXME: Is this really required still? +%patch -p1 -b .ia64 +%ifarch alpha +# FIXME: Is this really required still? +%patch3 -p1 -b .alpha +%endif +%patch1 -p1 -b .userland +%patch2 -p1 -b .shared +%patch4 -p1 +%patch5 -p1 + +%build +make PREFIX=%{_prefix} LIBDIR=%{_libdir} + +%install +rm -rf ${RPM_BUILD_ROOT} +make install FAKEROOT=${RPM_BUILD_ROOT} \ + LIBDIR=${RPM_BUILD_ROOT}/%{_lib} \ + SBINDIR=${RPM_BUILD_ROOT}/%{_sbindir} \ + INCDIR=${RPM_BUILD_ROOT}/%{_includedir} \ + MANDIR=${RPM_BUILD_ROOT}/%{_mandir}/ \ + COPTFLAG="$RPM_OPT_FLAGS" +mkdir -p ${RPM_BUILD_ROOT}/%{_mandir}/man{2,3,8} +rm -f doc/cap_set_fd* doc/cap_set_file* +#mv -f doc/*.2 ${RPM_BUILD_ROOT}/%{_mandir}/man2/ +#mv -f doc/*.3 ${RPM_BUILD_ROOT}/%{_mandir}/man3/ +cp %{SOURCE1} doc/ + +chmod +x ${RPM_BUILD_ROOT}/%{_lib}/*.so.* +rm -rf ${RPM_BUILD_ROOT}/%{_sbindir}/ +rm -rf ${RPM_BUILD_ROOT}/%{_includedir}/ +rm -rf ${RPM_BUILD_ROOT}/%{_lib}/*.so +rm -rf ${RPM_BUILD_ROOT}/%{_mandir}/man2/* +rm -rf ${RPM_BUILD_ROOT}/%{_mandir}/man3/* + +%post -p /sbin/ldconfig +%postun -p /sbin/ldconfig + +%files +%defattr(-,root,root) +/%{_lib}/*.so.* +%doc doc/capability.notes doc/capfaq-0.2.txt + +%clean +rm -rf ${RPM_BUILD_ROOT} + +%changelog +* Wed Nov 21 2012 Karsten Hopp 1.10-3 +- fix source URLs + +* Wed Oct 17 2012 Karsten Hopp 1.10-2 +- update patch + +* Tue Aug 24 2010 Karsten Hopp 1.10-1 +- package as compat-libcap1 + +* Tue Aug 17 2010 Karsten Hopp 1.10-26.kh +- include linux/types.h in capability.h + +* Tue Nov 14 2006 Karsten Hopp 1.10-26 +- remove obsolete manpages (#215402) + +* Wed Jul 19 2006 Karsten Hopp 1.10-25 +- add patch to support COPTFLAG (#199365) + +* Wed Jul 12 2006 Jesse Keating - 1.10-24.2.1 +- rebuild + +* Fri Feb 10 2006 Jesse Keating - 1.10-24.2 +- bump again for double-long bug on ppc(64) + +* Tue Feb 07 2006 Jesse Keating - 1.10-24.1 +- rebuilt for new gcc4.1 snapshot and glibc changes + +* Mon Dec 19 2005 Karsten Hopp 1.10-24 +- added development manpages +- as there are no manpages for the executables available, added at least + a FAQ (#172324) + +* Fri Dec 09 2005 Jesse Keating +- rebuilt + +* Mon Oct 31 2005 Steve Grubb 1.10-23 +- rebuild to pick up audit capabilities + +* Wed Mar 02 2005 Karsten Hopp 1.10-22 +- build with gcc-4 + +* Wed Feb 09 2005 Karsten Hopp 1.10-21 +- rebuilt + +* Tue Aug 31 2004 Phil Knirsch 1.10-20 +- Fix wrong typedef in userland patch (#98801) + +* Tue Jun 15 2004 Elliot Lee +- rebuilt + +* Tue Mar 02 2004 Elliot Lee +- rebuilt + +* Fri Feb 13 2004 Elliot Lee +- rebuilt + +* Tue Jan 27 2004 Karsten Hopp 1.10-17 +- use _manpath + +* Wed Jun 04 2003 Elliot Lee +- rebuilt + +* Wed Jan 22 2003 Tim Powers +- rebuilt + +* Sat Jan 4 2003 Jeff Johnson 1.10-14 +- set execute bits on library so that requires are generated. + +* Thu Nov 21 2002 Mike A. Harris 1.10-13 +- Removed %%name macro sillyness from package Summary, description text, etc. +- Removed archaic Prefix: tag +- lib64 fixes everywhere to use _lib, _libdir, etc +- Removed deletion of RPM_BUILD_DIR from %%clean section +- Added -q flag to setup macro +- Severely cleaned up spec file, and removed usage of perl + +* Fri Jul 19 2002 Jakub Jelinek 1.10-12 +- CFLAGS was using COPTFLAG variable, not COPTFLAGS +- build with -fpic +- apply the IA-64 patch everywhere, use capget/capset from glibc, + not directly as _syscall (as it is broken on IA-32 with -fpic) +- reenable alpha + +* Fri Jun 21 2002 Tim Powers +- automated rebuild + +* Wed May 29 2002 Bernhard Rosenkraenzer 1.10-10 +- Exclude alpha for now, apparent gcc bug. + +* Fri Nov 9 2001 Bernhard Rosenkraenzer 1.10-6 +- Fix sys/capabilities.h header (#55727) +- Move to /lib, some applications seem to be using this rather early + (#55733) + +* Mon Jul 16 2001 Trond Eivind Glomsr�d +- Add post,postun scripts + +* Tue Jul 10 2001 Jakub Jelinek +- don't build libcap.so.1 with ld -shared, but gcc -shared + +* Wed Jun 20 2001 Trond Eivind Glomsr�d +- Rebuild - it was missing for alpha + +* Wed Jun 06 2001 Florian La Roche +- add s390/s390x support + +* Thu May 17 2001 Bernhard Rosenkraenzer 1.10-1 +- initial RPM +- fix build on ia64